From FORRERJ@frl.orst.edu Tue Dec 06 11:59:53 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxF4B4-0000kcC; Tue, 6 Dec 94 11:59 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id CAAQ2629 for <HFSIG@tapr.org>; Tue, 6 Dec 1994 02:38:14 
-0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 6 Dec 94 9:59:02 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 6 Dec 94 9:58:39 PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Tue, 6 Dec 1994 09:58:39 PST8PDT 
Subject: HF Channel simulator 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <AQ1D8F158A9@frl.orst.edu> 
Hi all, 


I have received some extra copies of the CCIR report 549-2 
"HF IONOSPERIC CHANNEL SIMULATORS" from Barry. Anyone still in need for a 
copy please e-mail me. Thanks Barry! 


The simulator is coming along quite nicely - I have part implemented on the 
sound card DSP and the rest on the 486. The "flat fading" model 

is working in a fashion - the main problem presently is to make the 486 keep 
up with the sound card. I found that I had to implement quite a bit of the 
simulation work using table lookup methods instead of calls to the 486's FPU 
trancendental functions - just too slow. I'll share with you soon as that I 
have something that works reasonably well. 


73's 
--Johan, KC7WW 


From k5yfw@sacdm10.kelly.af.mil Tue Dec 06 12:45:03 1994 
Return-Path: <k5yfw@sacdm10.kelly.af.mil> 
Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOrF4s£-0001f£XC; Tue, 6 Dec 94 12:44 CST 
Received: by sacdm10.kelly.af.mil (5.65b/1.0.2-rct) 
id AA29948; Tue, 6 Dec 94 12:41:38 -0600 
Message-Id: <9412061841.AA29948@sacdm10.kelly.af.mil> 
Date: Tue, 6 Dec 94 12:41:37 -0600 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Re: [HFSIG:116] HF Channel simulator 
To: hfsig@tapr.org 
X-Orig-Date: Tue, 6 Dec 94 12:04 CST 
X-Orig-From: "Johan Forrer FL" <FORRERJ@fr1l.orst.edu> 
X-Orig-Message-Id: <AO1D8F158A9@frl.orst.edu> 


In your message of 6 Dec 1994 at 1204 CST, you write: 
Hi all, 


I have received some extra copies of the CCIR report 549-2 
"HF IONOSPERIC CHANNEL SIMULATORS" from Barry. Anyone still in need for a 
copy please e-mail me. Thanks Barry! 


The simulator is coming along quite nicely - I have part implemented on the 
sound card DSP and the rest on the 486. The "flat fading" model 

is working in a fashion - the main problem presently is to make the 486 keep 
up with the sound card. I found that I had to implement quite a bit of the 
simulation work using table lookup methods instead of calls to the 486's FPU 
trancendental functions - just too slow. I'll share with you soon as that I 
have something that works reasonably well. 


73's 


--Johan, KC7WW 


VVVVVV VV VV VV VV VV VV MV 


I too received a copy of the CCIR...thanks a whole bunch Barry. Now I 
will have to read it and try to understand it. Where's my old K&E 
slipstick? 


I too can make copies of the CCIR and will be happy to mail them... 
just E-Mail me at k5yfw@sat.ampr.org. 


FOR BARRY, I'd be very interested in getting the rest of REPORT 111, 
INFLUENCE ON LONG-DISTANCE HF COMMUNICATIONS...that starts on the 
last page of the CCIR you sent. I'll send postage. 


In other news, General xxxx (he doesn't want to be identified) of the 
Army, Army/MARS program wants xallx MARS traffic to start going by 
high speed data...HF/VHF/UHF, etc. I think he's sold on PACTOR. Ok 
suys#...time to shine and I *KNOW*x you can do it. 


Keep those E-Mail messages flowing...this is the most interesting 
mailgroup I subscribe to...and probably the most important. 


I'm anxiously awaiting for my copy of the CD "Seek You". See the 
review in the Jan '95 QST. 


73, 
Walt (dba k5y£w) 


## gender neutral from the NY "youse guys". 

From FORRERJ@frl.orst.edu Mon Dec 12 10:56:19 1994 

Return-Path: <FORRERJ@frl.orst.edu> 

Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxHE2r-OQOOOBbC; Mon, 12 Dec 94 10:56 CST 


Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAQ2031 for <HFSIG@tapr.org>; Mon, 12 Dec 1994 
01:35:19 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Mon, 12 Dec 94 8:54:50 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 12 Dec 94 8:54:28 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERIJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Mon, 12 Dec 1994 08:54:21 PST8PDT 
Subject: HF Channel simulator 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <A90CB2538A1@frl.orst.edu> 
Greetings, 


I am looking for volunteers to help validate the results of my HF channel 
simulator program. This is the version written in C. I am most 

interested in validating the statistics of the various fading paths - 
this needs to be obtained by several lengthy simulation runs. You would 
need to include your own statistic collection code, however, I will be 
happy to assist with this. 


As a minimum to participate, you would need a reasonably fast computer 
(something in the 486/33 class), a C compiler, and spread sheet/statistics 
analysis software. You would need to be able to read C code and be able to 
make a few code changes. I dont think this is rocket science - most of the 
background have been discussed on this SIG. 


If you are seriously interested, please e-mail - it is a short program so 
it can be e-mailed directly. 


Any help in this regard would be greatly appreciated. 


Thanks in advance and 73's 
Johan, KC7WW 


From FORRERJ@frl.orst.edu Wed Dec 14 16:19:56 1994 
Return-Path: <FORRERIJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrI237-00015iC; Wed, 14 Dec 94 16:19 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id GAA14356 for <HFSIG@tapr.org>; Wed, 14 Dec 1994 
06:58:43 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Wed, 14 Dec 94 14:18:24 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 14 Dec 94 14:18:15 
PST8PDT 


From: "Johan Forrer 

FL" <FORRERJ@frl.orst.edu> 

Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Wed, 14 Dec 1994 14:18:11 PST8PDT 
Subject: HF modulation schemes 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <AC632344275@frl.orst.edu> 
Hi all, 


Just thought that I would pass on word of a gem of a book that I have 
been studing over the past few days: 


"Principles and Practice of Multi-frequency telegraphy" by J.D Ralphs. 
Peter Peregrinus (1985). 


I saw it on a post to "rec.radio.amateur.digital.misc" and checked it 
out from our library. If it was not so expensive ($107), I would have 
considered buying a copy for my own reference. 


This book is about "Piccolo", i.e. MFSK and covers some great 

topics. It has, for instance the clearest non-math approach to explaining 
matched filters that I have seen. It also goes into great lengths of 
describing HF channel simulation and is a very useful extension of 

the materials on HF channel simulation previously posted on this SIG. Also 
includes a chapter on how it rates against other modulation schemes, i.e. 
the 16-parallel DPSK MIL-188 modem (actually does somewhat better). 


Food for thought. 
73's 


Johan, KC7WW 

From karn@qualcomm.com Fri Dec 16 00:56:19 1994 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOrIWa0-Q001P8C; Fri, 16 Dec 94 00:56 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.4) id WAAQ0937; 

Thu, 15 Dec 1994 22:58:01 -0800 

Date: Thu, 15 Dec 1994 22:58:01 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199412160658 .WAAQ0937@servo.qualcomm. com> 

To: hfsig@tapr.org 

Subject: December QEX on Clover tests 


The current issue of QEX has a rather interesting article on the 
results of some tests on Clover II using an HF channel simulator. 


The character error rate vs Eb/NO curves (no ARQ) are very 
telling. They compare several Clover data rates against a NATO HF 
modem standard, STANAG 4285. What's particularly interesting is that 


in both fading situations (1 and 2-path Rayleigh) STANAG 4285 
outperformed CloverII by 10 dB or more for the same data rate (300 
bps). 


The author attributes much of the difference to STANAG 4285's use of a 
3 Khz channel vs Clover's use of a 500 Hz channel. I think this 
illustrates very nicely the perils of narrowband thinking. Consider 
that STANAG 4285 not only requires less than 1/10 of the total 
transmitter power of Clover II for the same data rate, but it spreads 
it out over 6 times the bandwidth. This reduces the signal spectral 
density by more than 60x or 16 dB. That's a significant reduction in 
interference potential to others reusing the channel elsewhere. 


The article also mentions MIL-STD-110A, saying that it's very similar 
to (but incompatible with) STANAG 4285. Since we have a CD-ROM 
database of MIL-STDs at work, I was able to print off a copy (81 
pages). If someone is really interested in a copy, I could be 
persuaded to make some more and mail them out. 


Phil 


From frode@dxcern.cern.ch Fri Dec 16 02:42:32 1994 

Return-Path: <frode@dxcern.cern.ch> 

Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxIYFB-0000a1C; Fri, 16 Dec 94 02:42 CST 

Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA26274; Fri, 16 Dec 1994 09:42:19 +0100 

Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA19133; Fri, 16 Dec 1994 09:42:18 +0100 

From: frode@dxcern.cern.ch (Frode Weierud) 

Message-Id: <9412160842 .AA19133@dxcern.cern.ch> 

Subject: Re: [HFSIG:120] December QEX on Clover tests 

To: hfsig@tapr.org 

Date: Fri, 16 Dec 1994 09:42:17 +0100 (MET) 

In-Reply-To: <199412160658.WAAQ0937@servo.qualcomm.com> from "Phil Karn" at Dec 

16, 94 01:00:00 am 

X-Mailer: ELM [version 2.4 PL23] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 

Content-Length: 1414 


Hi Phil, 


The current issue of QEX has not yet arrived over here so 
I have not seen this article, but I am looking forward 
to study it. 


Concerning STANAG 4285 and other NATO standards I have tried 
several times to get access to them, but so far without any 
success. Most of them are classified, some even quite heavily, 
and I have not even got a reply to some of my requests. 


When I get the QEX article I will again try to approach the 
NATO standardisation people and see if I can get them to 
cooperate. 


I would like very much to have a copy of MIL-STD-188/110A, 
"INTEROPERABILITY & PERFORMANCE STANDARDS FOR DATA MODEMS", so 
if you can mail me a copy I will be extremely grateful. 


I will cover you costs for postage etc. Please let me know 

how I can reimburse you, with IRCs or a green bill in a letter. 
I would like to avoid sending you a cheque as I have to pay 
10.- SFr for each cheque and that is hardly worth it for small 
amounts. 


As Christmas is looming on the horizon I will take this 
opportunity to wish you a Merry Christmas and a Happy New Year. 


73 Frode, LA2RL 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKAAKK 


* Frode Weierud Phone : 41 22 7674794 x 

* CERN, SL Fax :? 41 22 7679185 * 

* CH-1211 Geneva 23 E-mail : frode@dxcern.cern.ch 
* 

* Switzerland or weierud@cernvm.cern.ch 
* 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKAKK 


From muphaus@cris.com Fri Dec 16 04:19:44 1994 

Return-Path: <Muphaus@cris.com> 

Received: from cris.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxIZ1G-0001A9C; Fri, 16 Dec 94 04:19 CST 

Received: from voyager.cris.com by cris.com [1-800-745-CRIS (voice) ] 

Received: by voyager.cris.com (4.1/SMI-4.1) 
id AAQ3227; Fri, 16 Dec 94 05:19:00 EST 

To: hfsig@tapr.org 

Cc: karn@qualcomm.com 

From: muphaus@cris.com (Marv Uphaus) 

Subject: Re: [HFSIG:120] December QEX on Clover tests 

Date: Fri, 16 Dec 1994 03:01:47 -0600 

Organization: Not Organized 

Reply-To: muphaus@cris.com 

Message-Id: <xTLykCysSUt8075yn@cris.com> 

In-Reply-To: <199412160658 .WAAQ0937@servo.qualcomm. com> 

Lines: 22 


On Fri, 16 Dec 94 01:00 CST, Phil Karn <karn@qualcomm.com> wrote: 
> Since we have a CD-ROM 


>database of MIL-STDs at work, I was able to print off a copy (81 
>pages). If someone is really interested in a copy, I could be 


>persuaded to make some more and mail them out. 


ANNA 
Phil... 
Shame on you...!!! This is electronic media... Find an FTP site to post 
it on and just make an electronic copy of the 81 pages and let whoever 
wants a copy FTP it and print it out themselves... Since it's already 


on CD-ROM that ought to take you about 1 minute to perform... 


BTW, Johan, the HFSIG needs an ftp site to post information, results, etc. 
that everyone can get to... Any suggestions from anyone... 


Marv... 


-- Marv Uphaus -- muphaus@cris.com -- Ph: 205-343-9256 -- 

-- U.S.Mail: 4031 Airport Blvd. #49 -- Mobile, AL 36608 -- 

-- Packet Radio Address -- K4BVG @W4IAX.#MOBAL.AL.USA.NA_ -- 

From karn@qualcomm.com Fri Dec 16 04:34:28 1994 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxIZzW-00017RC; Fri, 16 Dec 94 04:34 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.4) id CAAQ3282; 

Fri, 16 Dec 1994 02:36:03 -0800 

Date: Fri, 16 Dec 1994 02:36:03 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199412161036.CAAQ3282@servo.qualcomm. com> 

To: muphaus@cris.com 

CC: hfsig@tapr.org 

In-reply-to: <xTLykCysSUt8075yn@cris.com> (muphaus@cris.com) 

Subject: Re: [HFSIG:120] December QEX on Clover tests 


>Shame on you...!!! This is electronic media... Find an FTP site to post 
>it on and just make an electronic copy of the 81 pages and let whoever 
>wants a copy FTP it and print it out themselves... Since it's already 


>on CD-ROM that ought to take you about 1 minute to perform... 


The only problem is that the document is stored as an bitmap image on 
the CD-ROM and the only useful thing to do with it is to print it ona 
laser printer. I don't think the search software lets you do anything 
else with it. Even if it did, the resulting files would be rather large. 


Scanning it into ASCII is a possibility, but the image quality is 
rather poor (much like a low res fax) and there are tables and diagrams... 


Phil 


From rs@ife.ee.ethz.ch Fri Dec 16 05:04:48 1994 
Return-Path: <rs@ife.ee.ethz.ch> 
Received: from bernina.ethz.ch by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxIaSr-00002mC; Fri, 16 Dec 94 05:04 CST 
Received: from ife (actually ife-gw.ethz.ch) by bernina.ethz.ch 
with SMTP inbound; Fri, 16 Dec 1994 12:04:22 +0100 
From: Rolf Sommerhalder <rs@ife.ee.ethz.ch> 


Message-Id: <9412161104.AA15107@ife> 
Received: from ife.ee.ethz.ch (gillespie) by ife.ee.ethz.ch id AA15107; 
Fri, 16 Dec 1994 12:04:21 +0100 
Received: by gillespie.ethz.ch; Fri, 16 Dec 94 12:04:21 +0100 
Subject: Re: [HFSIG:123] Re: December QEX on Clover tests 
To: hfsig@tapr.org 
Date: Fri, 16 Dec 94 12:04:20 MET 
In-Reply-To: <199412161036.CAA03282@servo.qualcomm.com>; from "Phil Karn" at Dec 
16, 94 4:38 am 
content-length: 858 


> The only problem is that the document is stored as an bitmap image on 
> the CD-ROM ... 


Is that CD-ROM with Mil-Stds publically available ? If so, do you know its 
source ? 

(some Mil-Stds are available on the net, however, no the more recent/relevant 
HF-modem standards). 


73, 
Rolf 
--- kk * --- 


Rolf Sommerhalder 
Swiss Federal Institute of Technology (ETH) home address: 


Electronics Laboratory ETZ H60.1 c/o Rindlisbacher 
Gloriastrasse 35 Wermatswilerstrasse 96 

8092 Zurich / Switzerland 8610 Uster / Switzerland 
Voice +41 1 632 76 40 (or 632 51 53) Voice +41 1 941 59 28 

Fax +41 1 632 12 10 AX.25 HB9CWP @ HB90S 

E-Mail rolf.sommerhalder@ife.ee.ethz.ch Swiss Disaster Relief HBK81 


From gjones@tenet.edu Fri Dec 16 06:56:12 1994 

Return-Path: <gjones@tenet.edu> 

Received: from Gayle-Gaston.tenet.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOrIcCf£-Q00OQW1C; Fri, 16 Dec 94 06:56 CST 

Received: (from gjones@localhost) by Gayle-Gaston.tenet.edu (8.6.9/8.6.9) id 

GAAQ2166 for hfsig@tapr.org; Fri, 16 Dec 1994 06:56:08 -0600 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199412161256.GAA0Q2166@Gayle-Gaston.tenet.edu> 

Subject: Re: [HFSIG:122] Re: December QEX on Clover tests 

To: hfsig@tapr.org 

Date: Fri, 16 Dec 1994 06:56:07 -0600 (CST) 

In-Reply-To: <xTLykCysSUt8075yn@cris.com> from "Marv Uphaus" at Dec 16, 94 

04:21:00 am 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1222 


Please feel free to use the tapr area on tcet.unt.edu 


Hopefully we will be moving it over to tapr.org., but a few more things are 
required before we do that. 


Cheers - Greg 

According to Marv Uphaus: 

On Fri, 16 Dec 94 01:00 CST, Phil Karn <karn@qualcomm.com> wrote: 
> Since we have a CD-ROM 
>database of MIL-STDs at work, I was able to print off a copy (81 


>pages). If someone is really interested in a copy, I could be 
>persuaded to make some more and mail them out. 


ANNA 
Phil... 
Shame on you...!!! This is electronic media... Find an FTP site to post 
it on and just make an electronic copy of the 81 pages and let whoever 
wants a copy FTP it and print it out themselves... Since it's already 


on CD-ROM that ought to take you about 1 minute to perform... 


BTW, Johan, the HFSIG needs an ftp site to post information, results, etc. 
that everyone can get to... Any suggestions from anyone... 


Marv... 
-- Marv Uphaus -- muphaus@cris.com -- Ph: 205-343-9256 -- 


-- U.S.Mail: 4031 Airport Blvd. #49 -- Mobile, AL 36608 -- 
-- Packet Radio Address -- K4BVG @W4IAX.#MOBAL.AL.USA.NA_ -- 


VVVVV VV VV VV VV VV VV VV VV VV WV 


From frode@dxcern.cern.ch Fri Dec 16 07:34:10 1994 

Return-Path: <frode@dxcern.cern.ch> 

Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxIcnN-00005hC; Fri, 16 Dec 94 07:34 CST 

Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA20779; Fri, 16 Dec 1994 14:34:00 +0100 

Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA24122; Fri, 16 Dec 1994 14:32:48 +0100 

From: frode@dxcern.cern.ch (Frode Weierud) 

Message-Id: <9412161332.AA24122@dxcern.cern.ch> 

Subject: An introduction and an apology 

To: hfsig@tapr.org 

Date: Fri, 16 Dec 1994 14:32:47 +0100 (MET) 

In-Reply-To: <9412161104.AA15107@ife> from "Rolf Sommerhalder" at Dec 16, 94 

05:05:00 am 

X-Mailer: ELM [version 2.4 PL23] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 

Content-Length: 2911 


Hi all, 


As you have all seen that I exist, through my negligence 

of not checking the address field before hitting the Return 
key, I thought I at least could try to partly repair the 
damage by offering you a short introduction of myself. 


I have been following the discussions on the list for about 

a month now and I have already learned a few things I did not 
know. I have been interested in HF transmission modes for 
more than 25 years and I have during those year been trying 
to decode many, if not all, of the exotic modes you find on 
the HF bands. 


I am a licenced ham, LA2RL, but I have been living in the 
Geneva, Switzerland area for the past 22 years and for 

a large part of the time I have been unable to practice my hobby 
due to lack of a reciprocal licence. This made me into a 
"utility listener" which I still am, even if I rarely find 
the time to devote to this activity. Today I have a French 
temporary licence, F/LA2RL, but unfortunately I rarely have 
time for more than one QSO per week. I still hope to be 
able to find time to reactivate myself on the digital modes, 
and to again have some contacts on RTTY and Amtor and to try 
out the new Pactor mode. 


I have had the intention of informing you all about a few 
papers that I have found of interest. Some of the references 
I had in mind others have already found, so I will not repeat 
those, but here are a few additional references: 


You should try to have a closer look at a special issue of 
IEEE Journal on Selected Areas in Communications, Vol. SAC-5, 
No. 2, February 1987. This issue is dedicated to fading and 
multipath channel communications. 


Here are two of the papers that I have found interesting: 


- Seymour Stein; "Fading Channel Issues in System Engineering", 
pp.68-89. 


- Kenneth Brayer; "HF Data Transmission: Lessons from the Past, 
Directions for the Future", pp.90-101. 


I have also seen reference to two reports on single tone modems that 
it might be interesting to look at for those that would have 
access to them. They are: 


- D.D. McRae, R.S. LeFever, and J.N. York; "HF modem feasibility 
demonstration", RADC-TR-2-48, Final Tech. Rep., Mar. 1981 - 
Oct. 1981. 


- P. Monsen and L.C. Perry; "HF modem test and evaluation", 


RADC-TR-3-19, Final Tech. Rep., Jan. 1983. 


Over Christmas I plan to look through my old files and if I find 
other papers of interest I will let you all know. 


As I have already wished Phil a Merry Christmas and a Happy New 
Year I now want to make amends by wish you all happy festivities 
and a very fruitful and digital 1995. 


73 Frode, LA2RL 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAAK 


* Frode Weierud Phone : 41 22 7674794 * 

x CERN, SL Fax : 41 22 7679185 * 

* CH-1211 Geneva 23 E-mail : frode@dxcern.cern.ch 
* 

* Switzerland or weierud@cernvm.cern.ch 
* 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKAKK 


From muphaus@cris.com Sat Dec 17 11:51:18 1994 

Return-Path: <Muphaus@cris.com> 

Received: from cris.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrJ3Ho-O0000aUC; Sat, 17 Dec 94 11:51 CST 

Received: from voyager.cris.com by cris.com [1-800-745-CRIS (voice) ] 

Received: by voyager.cris.com (4.1/SMI-4.1) 
id AA17746; Sat, 17 Dec 94 12:50:37 EST 

To: hfsig@tapr.org 

From: muphaus@cris.com (Marv Uphaus) 

Subject: Re: [HFSIG:123] Re: December QEX on Clover tests 

Date: Fri, 16 Dec 1994 17:03:07 -0600 

Organization: Not Organized 

Reply-To: muphaus@cris.com 

Message-Id: <hoXykCysSgwWDO75yn@cris.com> 

In-Reply-To: <199412161036.CAA03282@servo.qualcomm. com> 

Lines: 26 


On Fri, 16 Dec 94 04:39 CST, Phil Karn <karn@qualcomm.com> wrote: 


>The only problem is that the document is stored as an bitmap image on 
>the CD-ROM and the only useful thing to do with it is to print it ona 
>laser printer. 


Phil... 


Post the file as a "filename.ps" (post script file) to tcet.unt.edu... 

Then anyone with access to a postscript printer (most people have a friend 
with one) can print it out... Another option would be to put the file ona 
WWW page in graphic form and then it can be looked at on-line... (but 
pretty slow even at 14400...) If you post it as a file somewhere, I will 
try some OCR software on it and see if we can convert it to ASCII and the 
diagrams to .BMP files... 


There are a lot of options besides printing it out in hardcopy... We 
should NEVER have to do that again... That was what the paper companies 
were afraid of years ago at the beginning of the computer revolution... So 
far it hasn't happened but it's close at hand...!!! 


73... Marv... 

-- Marv Uphaus -- muphaus@cris.com -- Ph: 205-343-9256 -- 
-- U.S.Mail: 4031 Airport Blvd. #49 -- Mobile, AL 36608 -- 
-- Packet Radio Address -- K4BVG @W4IAX.#MOBAL.AL.USA.NA_ -- 


From karn@unix.ka9q.ampr.org Sun Dec 18 02:10:31 1994 

Return-Path: <karn@unix.ka9q.ampr.org> 

Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOrJGhH-Q000Z8C; Sun, 18 Dec 94 02:10 CST 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id AAAQO0477; Sun, 

18 Dec 1994 00:10:35 -0800 

Date: Sun, 18 Dec 1994 00:10:35 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199412180810.AAAQ0477@unix.ka9q.ampr.org> 

To: muphaus@cris.com (Marv Uphaus) 

CC: hfsig@tapr.org 

In-reply-to: <hoxXykCysSgwWDO75yn@cris.com> (muphaus@cris.com) 

Subject: Re: [HFSIG:127] Re: December QEX on Clover tests 


The problem is that this is a proprietary packaged system, and there 
doesn't seem to be any way to get the data out of it in electronic form. 
I don't even know that it sends Postscript to the printer; it's an HP 
LaserJet III, so it could well be talking PCL for all I know. 


By the way, to whoever maintains this mailing list: items are coming 
out with a "Reply-To:" header that points to the list. That makes it 
difficult to reply privately to the sender of a message. This is not 
good in my opinion. 


Phil 


From k5yfw@k5yfw.ampr.org Sun Dec 18 09:23:17 1994 

Return-Path: <k5yfw@k5yfw.ampr.org> 

Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrJNS3-OQO000MvC; Sun, 18 Dec 94 09:23 CST 

Date: Sun, 18 Dec 94 08:17:44 CST 

Message-Id: <2355@k5yfw.ampr.org> 

From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW) 

Reply-To: k5yfw@sat.n5lyt.ampr.org 

To: hfsig@tapr.org, tcp-group@ucsd.edu, kd5i@kazak.nmsu.edu 

Subject: Re: Achieving regulation by bandwidth 

In-Reply-To: Your message of Fri, 16 Dec 1994 08:52:09 -0700 (MST) 

X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS) 


Seasons Greetings to you Karl and All. 


In message <Pine.SUN.3.91.941216082204 .24883C-100000@kazak> Karl writes: 


VV VV VV 


VVVVV WV 


VV VV VV VV 


It's a pet theory of mine. I believe that a standard "rice box" 
HF rig such as my Kenwood TS-140 has decient filtering in the IF for a 
voice. It seems to be matched very well to the 1200 baud FM modulated 
waveform used for years on VHF. I have experimented with other pbbs 
sysop's on 10 meters using 1200 baud. 


That would seem constant with my use of 1200 baud on 10 meter FM 
several years ago. But, I must comment that signals on the band 
very were stable. I suspect that I was getting little/few 
multi-path signals to cause distortion. However, at the first 
hint of signal degration, I would lose connectivity while the 
Signal strength was still strong. At that time, I didn't know 
Multi-path signal distortion. 


The results were spectacular! We had such good radio paths that 
we could use maxframes of 2 and 3! The data rate was comperable to that 
acheived on vhf if the pbbs were in the same town talking direct to each 
other. I didn't get a ticket from the FCC for using data on a voice only 
frequency. I didn't get anything. When propagation got bad we quit. 


As referenced above, it is (now to me) a well know fact that 
there is rapid fading observed on HF circuits that is the result 
of interference between a number of different waves that have 
been refracted from different portions of the ionosphere. Each 
refracted wave will arrive at the receive antenna as a slightly 
different time. This frequency or phase shift will mask a 
received data signal that has a baud rate generally above 150 
baud. 


With little or no multi-path signal distortion, 300 baud, and 
above is possible. However, in most cases you must be below 
150-200 baud to prevent this problem from causing detection 
problems. In severe cases, the problem may exist down to 100 
baud. 


Since the above applies to AFSK and FSK, my assumption is that 
FM AFSK would also be affected. 


I was running 1200 baud below 28.3 KHz. 


Reality says that 20 meters is where you need to be if you want 
to pass traffic on HF during a sunspot minimum. It has been shown that 
300 baud packet radio is not as viable as Pactor and some other software 
designed for the limited bandwidth we allow ourselves in the "CW" portion 
of the band. I say if we go to 1200 baud in the "Phone" portion of the 
band we will stir up some discussion and show that packet radio works 
well on HF. 


Please reference my comments above on multi-path signal 
distortion. 


I am willing to set up a 1200 baud packet forwarding frequency in 
the Extra Class portion of the band, say 14.54 MHz, lower sideband. I 
need at least another sysop willing to try this. The reason for doing 
this is 2 fold. It will measure how well 1200 baud works on 20 meters and 
provide some real data to show FCC at a future time when we want to argue 
for regulation by bandwidth used, not type of modulation. 


VVVVV VV 


I believe that someone else has referenece the fact that data 
transmissions are only authorized, in areas under control of the 
F.C.C. between 14.00 MHz and 14.15 MHz on the 20 meter band. 


Additionally, F.C.C. rules, Part 97.305 Authorized emission 
types, (97.307 Emission standards) authorizes only a "symbolic 
rate must not exceed 300 bauds, or for frequency shift keying, 
the frequency shift between the mark and space must not exceed 
1 KHz." 


Operating 1200 baud in the U.S. Phone band on 20 meters, if 
under the jurisduction of the F.C.C. Rules Part 97 is 
prohibited. However, the F.C.C. might allow experimenting if 
properly solicited. 


73, de karl k5di@k5di.nm.usa.na k5di@acca.nmsu.edu 
DOS and Windows some say are bad software, but facts 
do not support this. Bill Gates has more than a 
Billion dollars! 


VV VV VV 


There is a group who are interested in developing robust high speed 

data transmission protocols for HF. The thread(s) can be found by 
subscribing to "hfsig@tapr.org". For precise subscription directions, 
try sending E-Mail to listserv@tapr.org and in the text send only the 
work help...if this doesn't work, send the word info. But I'm willing 
to bet that someone like Greg Jones, will tell you just how to subscribe 
(are you reading this Greg?). 


My burning desire is to be able to run 2400 BPS on HF like the $7,500 to 
$15,000 modems that the military use only using an off-the-shelf 
computer sound card. The military runs 2400 BPS on HF with better 
thru-put than ten AMTOR stations at the same S:N ratio. I also want to 
be able to interface TCP/IP (SMTP) from V/UHF AmpxNet LANS to an HF 
AmprNet WAN. 


73, 
Walt@home.4.the.week-end 


From karn@unix.ka9q.ampr.org Sun Dec 18 23:52:12 1994 
Return-Path: <karn@unix.ka9q.ampr.org> 


Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOrJb10-Q000jFC; Sun, 18 Dec 94 23:52 CST 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id VAAQ1428; Sun, 

18 Dec 1994 21:52:55 -0800 

Date: Sun, 18 Dec 1994 21:52:55 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199412190552.VAA0Q1428@unix.ka9q.ampr.org> 

To: rs@ife.ee.ethz.ch 

CC: hfsig@tapr.org 

In-reply-to: <9412161104.AA15107@ife> (message from Rolf Sommerhalder on Fri, 16 

Dec 94 05:05 CST) 

Subject: Re: [HFSIG:124] Re: December QEX on Clover tests 


>Is that CD-ROM with Mil-Stds publically available ? If so, do you know its 
source ? 

>(some Mil-Stds are available on the net, however, no the more recent/relevant 
>HF-modem standards). 


My company subscribes to a commercial CD-ROM service for this stuff. I 
don't know much about it except the name: "Information Handling 
Services". Probably rather expensive, given the number of CD-ROMs. 


Phil 


From Rick_Whiting@ATK.COM Mon Dec 19 12:54:18 1994 
Return-Path: <Rick_Whiting@ATK.COM> 
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxJnDn-O0000w7C; Mon, 19 Dec 94 12:54 CST 
Received: from gateway1 by ATK.COM (8.6.9/8.6.9) 
id MAAQ6689; Mon, 19 Dec 1994 12:53:05 -0600 
Message-Id: <199412191853 .MAAQ6689@ATK. COM> 
Date: 19 Dec 1994 11:10:39 -0600 
From: "Rick Whiting" <Rick_Whiting@ATK.COM> 
Subject: FWD>RE>M4X- TMS320C4x Commu 
To: "Post hfsig TAPR" <hfsig@tapr.org> 
CC: Darrell_Sawyer@gateway1.ATK.COM 


MailxLink(r) SMTP FWD>RE>M4X: TMS320C4x Communica 


Date: 12/19/94 10:55 AM 

From: Rick Whiting 

In article <3cnkcp$pcu@tilde.csc.ti.com> 
Keith Larson <xkel@msg.ti.com> writes: 


> M4X EVALUATION SOFTWARE NOW AVAILABLE 

> 

> A Multiprocessing TMS320C4x Communications and Debug Kernel 
> 

> What is M4X and how do I get a copy 

> weeeeee eee ewww ewww www ew ew eww ew ew ew ew ew ew ew ew ee 


> M4X is a complete reference design for a multiprocessing system of 
TMS320C4x 
> devices. All materials for M4X are contained in one self extracting file 


> (M4X.EXE) which is available as freeware from the TMS320 BBS (713-274-2323) 
> where the original source will be maintained. Under a freeware agreement 
cee allowed to use, modify and freely distribute (IE no charge) this code 
ae as you provide reference to the original authors. 

‘ NOTE: At this time the M4X reference design is intended for evaluation 
use 


> only and will NOT be posted to TI's BBS ftp site until after the evaluation 
> period is completed. 

> 

> Who might be interested in M4Xx 

> weeeeewe eee eee ewww ewww ewww ew ew ew ew ew ew ew 


> This application is best suited for builders and hackers. To use this 

> application you will need to build your own interface card (less than $5 in 
> parts) and target system (more than $5) from the descriptions given in the 
M4X 

> documentation. M4X is intended for those individuals who are willing to 

> participate in the development of an open, user supported standard. If you 
> make significant advancements, please contact the original M4X developers 
to 

> have your ideas incorporated. 

> 

> Support 


> M4X will NOT be supported by the TMS320 Hotline. Instead, users should 
send 

> messages, comments and code to other M4X users through the TMS3230 BBS, or 
an 

> internet group, when and if it should form. 

> 

> What is contained in M4X.EXE 


>  M4X.EXE is a self extracting executable which contains several 

executables, 

> source files and documentation. The main files, and what they do, are 

given below. 

> 

> M4X.ASM - Assembly source code for TMS3204x runtime kernel. Provides 

> bi-directional split mode DMA and commport control for packetized 
routing of commands and data. 


> 
> 

> M4XD.EXE - Multiprocessing M4X debugger interface which runs ina 

> standard DOS window. Multiple DOS windows and debug nodes are 
> allowed. Sorry no source code can be made available for this 

> debugger! 

> 

> MANDEL40.EXE - Very fast multiprocessor version of the Mandelbrot set. 
> Runs a full screen SVGA capable of 640x480 256 colors 

> 
> 


MEMVIEW.EXE - Multiprocessor memory viewer which runs independent of other 
M4X 


> tasks. You can use this to asynchronously read and display data 


> blocks in a running system. 

> 

> Documentation - ICSPAT Conference paper (in postscript) and M4x 
documentation 


> are included. The M4X kernel and applications were first 
introduced 

> and demonstrated at the DSP World, ICSPAT conference in Dallas in 
> October 1994. 

> 

> Theory of Operation 

> sees ee ew wee ee ew ew ew ew ew ew ew 


> The M4x system utilizes the commport bootload feature of the TMS320C4x to 
> initialize an unknown system of processors in a wavefront bootload process. 


The bootload process detects all valid connections, no connects and null 
outputs and builds an interconnection matrix from the bootup data. 


> 
> 
> 
> When loaded the M4X kernel provides several low level functions which 

> are used to manage a multiprocessor system. The functions include getmem, 
> putmem, matrix management, call, branch, run, halt and singlestep. 

> 

> 

> 


The host communicates with the system through I/O driver and target 

command processing code. The I/O driver code interfaces with the hardware 
to 
> provide token, data strobe and fifo control. The target command software 
is 
> then responsible for sending and receiving packetized command streams from 
> the system. 
> 
> The application code provided shows a user how to interface applications 
to a 
> system in a general purpose and easy to use manner. Other important 
system 
> level functions which are provided include the system bootloader, coff file 
> loader, data transfer protocols, and simple run, stop and debug. 
> 
> Two I/0 circuits are given which can be used to connect a TMS320C4x 
commport 
> to a PC's printer port (needs to be bi-directional). These simple circuits 
> are designed to provide the neccessary buffering and logic through software 
> control to achieve a bi-directional general purpose link to a TMS320C4x 
comport. 
> Since all of the printer port signals are uni-directional, simple 
buffering 
> techniques can be used to provide links of unlimited distance. This 
interface 
> is also easily converted to other processors such as the TMS320C3x. 
> 
> Conclusion 


> M4X has been developed to provide a starting point for the low level BIOS 
> framework of a multiprocessing system. When coupled with higher levels of 
> functionality there are many possabilities. At this time it is definitely 
NOT 

> complete and still needs lots of work. It just takes time and effort! 

> 

> Best regards, 

> Keith Larson 

> 

> Disclaimers 


Vv 


They said it could'nt be done, so I did it! 


If you follow the rules that everybody else follows, you are 
doomed to repeat the actions of everybody else! 


There is no such thing as a free lunch! 
I have been known to make a mistake or two, this is how I learn! 
If you see a bug.. Kill it first! Then give me a call. 


Yes, I also created the C26 DSK... and I am very busy. 


VV VV VV VV VV VV OV 


| Rick Whiting Office Phone 612-931-5344 

| 5780 Rosewood Lane N. Home Phone 612-550-1213 

| Plymouth, MN 55442 Fax 612-931-5735 

| U.S.A. E-mail rick_whiting@atk.com 

| Packet WOTN @ WBOGDB.MN.USA.NOAM 


From Rick_Whiting@ATK.COM Mon Dec 19 13:47:53 1994 
Return-Path: <Rick_Whiting@ATK.COM> 
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrJo1lu-OQOOOVEC; Mon, 19 Dec 94 13:45 CST 
Received: from gateway1 by ATK.COM (8.6.9/8.6.9) 
id NAAQ7633; Mon, 19 Dec 1994 13:43:53 -0600 
Message-Id: <199412191943 .NAAQ7633@ATK.COM> 
Date: 19 Dec 1994 11:08:41 -0600 
From: "Rick Whiting" <Rick_Whiting@ATK.COM> 
Subject: FWD>RE>New 56002 Evaluation 
To: "Post hfsig TAPR" <hfsig@tapr.org> 
CC: Darrell_Sawyer@gateway1.ATK.COM 


MailxLink(xr) SMTP FWD>RE>New 56002 Evaluation Mod 


Date: 12/19/94 10:55 AM 


From: Rick Whiting 
In article <kirk.787276719@mustang18> 
kirk@rtsg.mot.com (Michael J. Kirk) writes: 


Please excuse me if this info has 

already been posted. I just wanted to share 

this with anyone who might be interested in a low 
cost DSP evaluation tool. I found it listed in the 
October 1994 issue of DSP & Multimedia Technology. 


WHO: Motorola Semiconductor Products Sector 
Digital Signal Processor Division 
(512) -891-3717 


WHAT: A DSP56002 evaluation module containing: 
Hardware: 
Fully assembled and tested printed circuit board with 
DSP56002, 24 bit fixed point DSP, 40MHz 
32k X 24 external SRAM 
Crystal Semiconductor MWAVE CS4215 Stereo Codec 
MC7805ACT voltage regulator 
MCHC705K1 microcontroller for RS232 to OnCE interface 
MC33078 preamp for analog buffering 
Jacks for stereo inputs, outputs and headphones 
Documentation for DSP56002, CS4215, ASSEMBLER, and 
DEBUGGER plus board schematics 
Software: 
Motorola's DSP5600x cross assembler for PCs 
Domain Technologies debug software with (DOS?) 
based windowed interface, SYMBOLIC DEBUGGING! 
Installation instructions 
Demo software and self test files 
Requirements: 
User must provide: 
Power supply (7-9V AC or DC) with spade terminals or 
2.1 mm plug 
RS-232 cable with DB-9 connectors 
IBM PC compatible (-386 class or higher) running 
MS-DOS with 19200 baud serial port 
Options: 
32k X 8 EEPROM for bootstrapping and stand-alone operation 
second RS-232 connector for access to DSP56002 SCI port 
second crystal for other sample rates, e.g. 44.1kHz 


HOW MUCH: US$ 149.95 + shipping and applicable taxes 
Includes everything in WHAT above. 


WHERE: This offer may not be available outside the US 
check with your local Motorola sales office. 


WHEN: Available now. 


VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV OV 


WHY: To get more people using Motorola DSP's 


To offer an alternative to TI's US$99 evaluation kit 
All for now... 
Mike Kirk 


Senior Engineer 

Motorola, Inc. 

Cellular Infrastructure Group 
1475 W. Shure Drive 

Arlington Heights, IL 60004 


VVVVVV VV VV 


| Rick Whiting Office Phone 612-931-5344 

| 5780 Rosewood Lane N. Home Phone 612-550-1213 

| Plymouth, MN 55442 Fax 612-931-5735 

| U.S.A. E-mail rick_whiting@atk.com 

| Packet WOTN @ WBOGDB.MN.USA.NOAM — | 


From karn@unix.ka9q.ampr.org Mon Dec 19 16:04:37 1994 

Return-Path: <karn@unix.ka9q.ampr.org> 

Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOrJqBx-0001BuC; Mon, 19 Dec 94 16:04 CST 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id OAAQ2330; Mon, 

19 Dec 1994 14:03:50 -0800 

Date: Mon, 19 Dec 1994 14:03:50 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199412192203 .OAAQ2330@unix.ka9q.ampr.org> 

To: k5yfwe@k5yfw.ampr.org 

CC: hfsig@tapr.org 

Reply-To: karn@qualcomm.com 

In-reply-to: <2355@k5yfw.ampr.org> 

Subject: Re: [HFSIG:129] Re: Achieving regulation by bandwidth 


With little or no multi-path signal distortion, 300 baud, and 
above is possible. However, in most cases you must be below 
150-200 baud to prevent this problem from causing detection 
problems. In severe cases, the problem may exist down to 100 
baud. 


VV VV MV 


So don't use a high baud rate. This implies multiple bits per 
transmitted symbol (channel state change). This can be done either 
orthogonally or non-orthogonally. Orthogonal simply means that all of 
the possible channel states can be detected independently, without 
mutual interference. Binary FSK with a sufficiently wide shift for the 
baud rate is the classic example; you can build a "tone filter" that 
responds just to mark, and another one that responds only to space. 


But nothing limits FSK to just two tones. If you used, say 256 
distinct tones then you could encode the 256 possible combinations of 


an 8-bit data symbol as one of the 256 tones. This would be 256-ary 
FSK. The general scheme is called m-ary FSK and has long been known 
to be one of the best schemes around for fading HF channels. The 
higher the value of m, the better the performance -- assuming you can 
spare the bandwidth. 


The most common NON-orthogonal signalling scheme for multiple bits per 
transmitted symbol is QAM. This maps a n-bit data symbol into 24n 
possible combinations of carrier amplitude and phase. QAM's big 
advantage is very good bandwidth efficiency for large values of n, 
which is why it's universal in telephone line modems. But big values 
of n mean very closely packed signal constellations, and relatively 
little noise is required to move one received signal state to another 
one nearby and cause an error. So the bandwidth efficiency of QAM 
comes at the price of a much higher required S/N ratio. This is again 
okay for telephone modems where the S/N ratio is usually 30 dB or 
more, but (in my opinion) it is completely inappropriate for noisy, 
interference-prone radio channels. 


So once again we're back to the conclusion that to build a decent HF 
modem that provides a good link with minimum transmitter power, we 
really need to do something to relax the bandwidth limits. 


Phil 
From FORRERJ@frl.orst.edu Mon Dec 19 17:09:17 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrJrCc-OOO1HTC; Mon, 19 Dec 94 17:09 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id HAAO1298 for <hfsig@tapr.org>; Mon, 19 Dec 1994 
07:47:51 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Mon, 19 Dec 94 15:07:40 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 19 Dec 94 15:07:09 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 19 Dec 1994 15:07:05 PST8PDT 

Subject: Re: [HFSIG:133] Re: Achieving regulation by bandwidth 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <B3F06525272@frl.orst.edu> 
Phil Karn wrote: 


>So don't use a high baud rate. This implies multiple bits per 
>transmitted symbol (channel state change). This can be done either 
>orthogonally or non-orthogonally. Orthogonal simply means that all of 
>the possible channel states can be detected independently, without 
>mutual interference. Binary FSK with a sufficiently wide shift for the 
>baud rate is the classic example; you can build a "tone filter" that 


>responds just to mark, and another one that responds only to space. 


>But nothing limits FSK to just two tones. If you used, say 256 
>distinct tones then you could encode the 256 possible combinations of 
>an 8-bit data symbol as one of the 256 tones. This would be 256-ary 
>FSK. The general scheme is called m-ary FSK and has long been known 
>to be one of the best schemes around for fading HF channels. The 
>higher the value of m, the better the performance -- assuming you can 
>spare the bandwidth. 


As supporting arguments to above, please see J.D. Ralphs's book: 

Principles and practice of multi-frequency telegraphy. Peter Peregrinus, 
ISBN 0-86341-022-7. This book includes extensive chapters on 

how such a system is engineered around the symbol set and signaling rate to 
combat the properties of the HF channel. It also compares this m-FSK to the 
MIL-STD-188A 16-tone parallel modems and comes out a nose ahead of the 
pack. The book also describes a simple synchronous detector that would 

be quite simple to implement on our present DSP platforms. If you are 
interested in using an HF channel simultor this reference also contains 
very useful stuff. 


>The most common NON-orthogonal signalling scheme for multiple bits per 
>transmitted symbol is QAM. This maps a n-bit data symbol into 24n 
>possible combinations of carrier amplitude and phase. QAM's big 
>advantage is very good bandwidth efficiency for large values of n, 
>which is why it's universal in telephone line modems. But big values 
>of n mean very closely packed signal constellations, and relatively 
>little noise is required to move one received signal state to another 
>one nearby and cause an error. So the bandwidth efficiency of QAM 
>comes at the price of a much higher required S/N ratio. This is again 
>okay for telephone modems where the S/N ratio is usually 30 dB or 
>more, but (in my opinion) it is completely inappropriate for noisy, 
>interference-prone radio channels. 


The possibilities of QAM is quite attractive. Its signaling 

constallation is shown to have distinct robustness over other 

alternative schemes of phase/amplitude signaling especially under 
conditions that include conditions of phase jitter (please see the Foschini 
paper that I posted a while ago). 


I have been thinking about the possibilities of QAM especially after 
reading Ralphs' book. He describes a simple procedure that is based on 

a simple synchronization sequence, and once lock is achieved, the PLL stays 
locked during the remainder of the frame (he gives supportive arguments of 
its merits). If the signalling rate is chosen appropiately, the system will 
tolerate a considerable amount of phase distortion. I would like to invite 
further comments on this type of idea. I am not sure why, if this is such a 
scheme is this good, why have we not seen more general acceptance? 


>So once again we're back to the conclusion that to build a decent HF 


>modem that provides a good link with minimum transmitter power, we 
>really need to do something to relax the bandwidth limits. 
>Phil 


Ditto - it is inevitable, however, even 1kHz would take us a long way and 
this is within part 97. 


73's 


Johan, KC7WW 
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Date: Mon, 19 Dec 1994 17:58:16 -0600 (CST) 
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19, 94 04:06:00 pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 308 


According to Phil Karn: 

> So once again we're back to the conclusion that to build a decent HF 
> modem that provides a good link with minimum transmitter power, we 

> really need to do something to relax the bandwidth limits. 


How wide are we talking Phil ? 
Which bandwidth limits are you discussing? 
Greg 


From karn@unix.ka9q.ampr.org Mon Dec 19 20:05:44 1994 
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From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199412200206.SAAQ3125@unix.ka9q.ampr.org> 

To: FORRERJ@fr1.orst.edu 

CC: hfsig@tapr.org 

In-reply-to: <B3F06525272@frl.orst.edu> (FORRERJ@fr1.orst.edu) 

Subject: Re: [HFSIG:134] Re: Achieving regulation by bandwidth 


Reply-To: karn@qualcomm.com 


>The possibilities of QAM is quite attractive. Its signaling 

>constallation is shown to have distinct robustness over other 

>alternative schemes of phase/amplitude signaling especially under 
>conditions that include conditions of phase jitter (please see the Foschini 
>paper that I posted a while ago). 


I'm not convinced. QAM requires phase-coherent detection, but the HF 
channel is inherently phase random. A Rayleigh fading channel model 
has a Rayleigh probability distribution on amplitude (hence the name) 
and a uniform distribution of phase between 0 and 2pi - i.e., the 
received phase is completely random and can carry no information due 
to the constantly changing and unpredictable propagation path lengths. 
Although you might be able to get away with phase modulation on some 
particularly benign HF channel, especially if there are only a small 
number of path components, it sure doesn't seem like a wise thing to 
rely on in your design. 


So this implies noncoherent demodulation, i.e., just looking at signal 
energy and ignoring phase. m-ary FSK can be demodulated this way. As 
you increase m towards infinity you not only gain back everything you 
lost by going noncoherent, but you also approach the -1.6dB Shannon 
limit! 


This stuff actually works. Although the details and implementation are 
quite different, Qualcomm's CDMA system uses 64-ary modulation on the 
reverse (mobile-to-cell) link in order to make up for the lack of a 
coherent carrier phase reference over the Rayleigh-faded mobile radio 
channel. The orthogonal codes are Walsh functions over time instead of 
collections of sine waves over frequency, but the same principles 
apply. 


--Phil 
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Date: Mon, 19 Dec 1994 18:27:53 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199412200227 .SAAQ3205@unix.ka9q.ampr.org> 

To: gjones@tenet.edu 

CC: hfsig@tapr.org 

In-reply-to: <199412192358.RAA13787@Gayle-Gaston.tenet.edu> (message from Greg 

Jones on Mon, 19 Dec 94 18:01 CST) 

Subject: Re: [HFSIG:135] Re: Achieving regulation by bandwidth 


>Which bandwidth limits are you discussing? 


Those on the bottom half of each HF band. 


>How wide are we talking Phil ? 


As wide as possible, as long as we stay in the band. For short-term 
practical reasons, a good start would be 2-3 Khz. That fits in a SSB 
filter so existing HF transceivers could be used without modification 
by simply writing the appropriate DSP code to drive them with baseband 
audio. 


>Which bandwidth limits are you discussing? 
Those on the bottom half of each HF band, where "data" is allowed. 


Phil 
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Subject: TAPR 1995 Annual meeting 
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X-mailer: PMail v3.0 (Ria) 


Message-ID: <B50DDD479AB@frl.orst.edu> 
Hi all, 


I hope that everyone is giving this meeting serious thought? 

If you are interested in DSP, and you should by now (?). This 

will be a good place to be. This will be an excellent opportunity to 

get first-hand impressions on what are being done and also an 

opportunity to attend the seminars. I am looking forward to hearing 

Phil's presentation on "Error correction coding". This is, in my 

opinion, a key component in a modern communication system. It's just a 
shame that the two planned seminars are in a time conflict as I would have 
loved attending the DSP-93 seminar too. Is there any possibility 

in re-arranging these venues? 


I have also been approached to present a paper, and though, public speaking 
is not my favorite passtime, I will consider a topic. I have sufficient 
materials on two topics: 


1) An implementation of PACTOR on a PC. This could look at the Pactor 
protocol, its good and not-so-good aspects, how frame sync is achieved and 
maintained through brute-force algorithms, memory ARQ, and how this 

is integrated into the sound card's DSP. 


2) The "HFSIG" HF channel simulator. This could include the Watterson model, 
a summary of various bits and pieces as contributed on this SIG, and my 
simple PC/DSP-sound card implementation. 


Suggestions? 


73's, Johan KC7WW 
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Date: Tue, 20 Dec 1994 09:23:38 PST8PDT 

Subject: Re: [HFSIG:133] Re: Achieving regulation by bandwidth 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <B514DCB4577@frl.orst.edu> 


Phil Karn wrote: 


>>The possibilities of QAM is quite attractive. Its signaling 
>>constallation is shown to have distinct robustness over other 
>>alternative schemes of phase/amplitude signaling especially under 
>>conditions that include conditions of phase jitter (please see the 
>>Foschini >paper that I posted a while ago). 


>I'm not convinced. QAM requires phase-coherent detection, but the HF 
>channel is inherently phase random. A Rayleigh fading channel model 
>has a Rayleigh probability distribution on amplitude (hence the name) 
>and a uniform distribution of phase between © and 2pi - i.e., the 
>received phase is completely random and can carry no information due 
>to the constantly changing and unpredictable propagation path lengths. 
>Although you might be able to get away with phase modulation on some 
>particularly benign HF channel, especially if there are only a small 
>number of path components, it sure doesn't seem like a wise thing to 


>rely on in your design. 


>So this implies noncoherent demodulation, i.e., just looking at signal 
>energy and ignoring phase. m-ary FSK can be demodulated this way. As 
>you increase m towards infinity you not only gain back everything you 
>lost by going noncoherent, but you also approach the -1.6dB Shannon 
>limit! 


Yes that is quite true if you consider doing things the way its done 
on telco circuits, 


i.e. "matched filter" == coherent demodulation + integrate&dump + 
thresholding. 


It would be really valuable getting hold of Ralph's book and see the 

logic of relaxing the coherent demodulation requirement. He calls it 
"quasi" 

coherent detection and still uses matched filters, though at passband, i.e. 
filters engineered and spaced as matched filters at passband instead of at 
baseband. I am sure that using this scheme I can implement DPSK + at least 
some form of amplitude modulation like being done on Clover. Although this 
is not quite the same as true QAM by definition, we can still 

achieve multiple bits per baud and also enjoy the bandwidth efficiency 
benefits. Does this make any sense - is it worth looking into? 


---further stuff deleted --- 
I think we are making progress - keep up the good work. 
73's, Johan, KC7WW 
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X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1280 


According to Johan Forrer 

FL: 

> I hope that everyone is giving this meeting serious thought? 
> If you are interested in DSP, and you should by now (?). This 


will be a good place to be. This will be an excellent opportunity to 

get first-hand impressions on what are being done and also an 

opportunity to attend the seminars. I am looking forward to hearing 

Phil's presentation on "Error correction coding". This is, in my 

opinion, a key component in a modern communication system. It's just a 
shame that the two planned seminars are in a time conflict as I would have 
loved attending the DSP-93 seminar too. Is there any possibility 

in re-arranging these venues? 


VVVVVV VV 


Hum -- interesting comment. I'll talk to Phil, Bob, and Mel and see what we 
might be able to do. I should have realized this when Mel and myself sat 
down and did the inital schedules. 


The reason for finishing up around noon is to give folks a chance to fly out 
the rest of the afternoon. If a session is from 1pm till 4 or 5pm will 
people stay and be able to get their flight out. or maybe shoten PHil's a 
tad and Bob's a tad, but people will still want to go to lunch sometime :-) 
You can see the problems. 


Greg 
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Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
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Subject: Re: [HFSIG:133] Re: Achieving regulation by bandwidth 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <B51ED1660BE@frl.orst.edu> 
Hi all, 


Phil, it may help a great deal and be very beneficial to a lot of us if you 
could be so kind and, in a paragraph or so, explain what is meant by: 


Channel capacity (entropy), 
Spectral occupancy, 


Bandwidth efficiency, 


and how all this eventually relates to the Shannon limit. 


I'm certain that understanding these definitions will help us understand 
better what we are trying to achieve. From your past postings, you have a 
great talent for making such stuff clear. 


Thanks a lot in advance. 


73's, Johan, KC7WW 
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Subject: Re: [HFSIG:138] TAPR 1995 Annual meeting 
In-Reply-To: <B50DDD479AB@fr1.orst.edu> 
Message-Id: <Pine.SUN.3.90.941220095521 .28112U-100000@daffyduck> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Tue, 20 Dec 1994, Johan Forrer FL wrote: 


> 

> I have also been approached to present a paper, and though, public speaking 
> is not my favorite passtime, I will consider a topic. I have sufficient 

> materials on two topics: 

> 

> 

> Suggestions? 

> 


How about a summary of the issues that have been debated on this net? For 
instance: 


* Is more bandwidth for digital HF channels necessary/desirable/feasible? 
* What modulation techniques are presently under evaluation? What are the 
pros and cons of each. 

*x DSP platforms for HF signal processing: pros and cons of different 
makes, writing portable code. 


All of this may be self-evident to those who have been following this 
group for a while, but to outsiders a summary could be instructive. 


Hugh 
From FORRERJ@frl.orst.edu Tue Dec 20 14:22:05 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxKB4L-0000dCC; Tue, 20 Dec 94 14:22 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id FAAQ5308 for <hfsig@tapr.org>; Tue, 20 Dec 1994 
05:01:06 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 20 Dec 94 12:20:56 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 20 Dec 94 12:20:40 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
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Subject: Re: [HFSIG:142] Re: TAPR 1995 Annual meeting 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <B5440926DB3@frl.orst.edu> 
On Tue, 20 Dec 1994, Hugh Shane wrote: 


>> 

>> I have also been approached to present a paper, and though, public 
speaking 

>> is not my favorite passtime, I will consider a topic. I have sufficient 
>> materials on two topics: 

>> 


>> 
>> Suggestions? 
>> 


>How about a summary of the issues that have been debated on this net? For 
>instance: 


>*x Is more bandwidth for digital HF channels necessary/desirable/feasible? 
>x What modulation techniques are presently under evaluation? What are the 
>pros and cons of each. 


I'm afraid that I have to pass this one to someone more capable as 
I don't think that I can do justice that these deserve. How about you Hugh? 


>x DSP platforms for HF signal processing: pros and cons of different 
>makes, writing portable code. 

>All of this may be self-evident to those who have been following this 
>group for a while, but to outsiders a summary could be instructive. 


I can consider this one, if it is not taken as a cheap shot at the 
TAPR-93. How does others feel about it? Let us hear your suggestions. 


73's 


Johan, KC7WW 
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Message-Id: <9412202217 .AAQ06592@eagle.sr.hp.com> 

Subject: HF Modulation Modes 

To: hfsig@tapr.org 

Date: Tue, 20 Dec 1994 14:17:39 -0800 (PST) 

X-Mailer: ELM [version 2.4 PL21] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 

Content-Length: 3080 


I haven't posted to a list before, so let's see if this works... 


In all the discussion about the best modulation format for HF, I'm 
surprised nobody has mentioned OFDM. Oxthogonal frequency-division 
multiplex is proposed for Digital Audio Broadcasting and digital TV 
in Europe, although it is not so well known in the US. 


The idea is to split the signal up into a large number (like 128 or 
1024) equally-spaced carriers, each modulated at the same symbol rate. 
I believe the DAB standard proposes that each carrier be modulated 
with QPSK, but you can use any modulation in which each symbol can be 
represented by a phase and amplitude. That includes the many forms of 
QAM, PSK, PI/4 DQPSK, on-off keying, whatever. 


For example, If you use 128 carriers, the symbol rate is reduced by 


a factor of 128, greatly reducing the probability of inter-symbol 
interference due to multipath propagation. Adding forward error 
correction and time and frequency interleaving reduces the probability 
of bit errors due to selective fading on one or more carriers. 


The reason the mode is called "orthogonal" FDM is that the carrier 
frequency spacing is 1/symbol period, which theoretically eliminates 
interference from all unwanted carriers. This is easiest to see in 
the time domain. For a symbol rate of 1 symbol/s, the carriers will 
be spaced 1 Hz apart. During each symbol period, the detector for 
each carrier receives a certain number of RF cycles of the desired 
carrier. During that same time period, each unwanted carrier has a 
number of cycles that differ from the desired carrier by an integer. 
Convolving two sine waves that differ by an integer number of cycles 
gives zero result. 


You could implement OFDM by building 128 RF oscillators, 128 I/Q 
modulators, and the associated controlling hardware. But there's a 
much simpler way, and here's the clever part of OFDM: 


I mentioned that the signal consists of a series of equally-spaced 
RF signals, each characterized by an amplitude and a phase. If you 
do an inverse DFT on that data, you come out with the time samples 
of the composite signal! At the kinds of data rates we are talking 
about, an inexpensive DSP would be plenty fast enough. For example, 
a 12.5 MHz ADSP21xx can do a 256-point DFT in 0.59 ms. So we're 
talking about a $10 DSP and a single I/Q modulator running at very 
low symbol rates. 


For example, 128 QPSK carriers spaced 7.5 Hz apart (7.5 baud) gives 
1920 bits per second within the 1 kHz bandwidth limit. The DSP 
has 1/7.5 = 133 ns to do all its calculations. 


The choice of modulation type for the carriers affects only the 
amplitude/phase list for each symbol. So it would be easy to 
change modulation types to respond to different propagation 
conditions, ala Clover. By including the capability to do various 
size FFTs, different symbol rates could be implemented using the 
same bit rate within the same bandwidth. i.e. use very slow 
symbol rates (large FFT) under fast Rayleigh fading conditions 

and faster symbol rates (small FFT) with slow flat fading. 


Alan Bloom N1AL 
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(8.6.9/8.6.9) with SMTP id HAAQ6074 for <hfsig@tapr.org>; Tue, 20 Dec 1994 
07:49:38 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 20 Dec 94 15:09:29 PST8PDT 


Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 20 Dec 94 15:09:05 
PST8PDT 

From: "Johan Forrer 

FL" <FORRERJ@frl.orst.edu> 

Organization: Forest Research Lab. Oregon State 

To: hfsig@tapr.org 


Date: Tue, 20 Dec 1994 15:08:58 PST8PDT 
Subject: Re: [HFSIG:144] HF Modulation Modes 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <B570F42212D@frl.orst.edu> 

Alan Bloom wrote: 

>I haven't posted to a list before, so let's see if this works... 
Welcome Al - glad you found us. 

--some stuff deleted --- 


>The idea is to split the signal up into a large number (like 128 or 
>1024) equally-spaced carriers, each modulated at the same symbol rate. 
>I believe the DAB standard proposes that each carrier be modulated 
>with QPSK, but you can use any modulation in which each symbol can be 
>represented by a phase and amplitude. That includes the many forms of 
>QAM, PSK, PI/4 DQPSK, on-off keying, whatever. 


If I understand it correctly, I do believe that the 39-tone parallel 
MIL-STD-188 modem that have been mentioned on this group, is based on 
a similar principle - if I understand it correctly? 


-- more stuff deleted -- 


>I mentioned that the signal consists of a series of equally-spaced 
>RF signals, each characterized by an amplitude and a phase. If you 
>do an inverse DFT on that data, you come out with the time samples 
>of the composite signal! At the kinds of data rates we are talking 
>about, an inexpensive DSP would be plenty fast enough. For example, 
>a 12.5 MHz ADSP21xx can do a 256-point DFT in 0.59 ms. So we're 
>talking about a $10 DSP and a single I/Q modulator running at very 
>low symbol rates. 


>For example, 128 QPSK carriers spaced 7.5 Hz apart (7.5 baud) gives 
>1920 bits per second within the 1 kHz bandwidth limit. The DSP 
>has 1/7.5 = 133 ns to do all its calculations. 


>The choice of modulation type for the carriers affects only the 
>amplitude/phase list for each symbol. So it would be easy to 
>change modulation types to respond to different propagation 
>conditions, ala Clover. By including the capability to do various 
>size FFTs, different symbol rates could be implemented using the 
>same bit rate within the same bandwidth. i.e. use very slow 
>symbol rates (large FFT) under fast Rayleigh fading conditions 


>and faster symbol rates (small FFT) with slow flat fading. 


This is interesting - one question: did we overcome the need for 
coherent detection, or does it matter? 


73's 


Johan, KC7WW 
From FORRERJ@frl.orst.edu Tue Dec 20 18:26:51 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrKEtE-O000vTC; Tue, 20 Dec 94 18:26 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id JAAQ6450 for <hfsig@tapr.org>; Tue, 20 Dec 1994 
09:05:54 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 20 Dec 94 16:25:44 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 20 Dec 94 16:25:39 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 20 Dec 1994 16:25:36 PST8PDT 
Subject: Re: [HFSIG:145] Re: HF Modulation Modes 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <B5855F80B9A@frl.orst.edu> 


Some further food for thought: 


Here are some further details on the 16-tone MIL-STD-188C modem 
and a comparitive M-FSK system, just for interest sake. 


This MIL-STD modem uses 16 simultaneous tones, each modulated at 75 baud 
(13.3 ms elements) in two or four phases giving a maximal rate of 
2x75x16=2400 bit/s in 3 kHz. The tones are spaced at 110 Hz, orthoganal 
for the matched filter integration period of 9.1 ms, which allows for a 
guard time of +/- 2ms to cater for a limited degree of sych. error. 

The provision of guard periods causes an effective power loss of 

1.75 dB. Assuming each tone quadrature modulated, the normalized bandwidth 
is 3 Hz/bit/s. However, extending this to 16 parallel tones, this yields 
@.87 Hz/bit/s, which is pretty close to the ultimate. 


I have some further specifications on its BER, but unfortunately not 
with me at the moment. Walt, K5YFW, could perhaps attest how these 
have been doing on the military HF nets. This is living proof that 
phase modulation is worth considering on HF. 


One consideration when dealing with such a multi-tone signaling system, 
that the power rating of the transmitter is rated on the assumption that a 
single unmodulated carrier is radiated, however, with multiple tones 


the output power is reduced by the square of the number of tones. Also 
remember that, when dealing with the combination of such multiple tones 
that a "noise-like" waveform results with possibly high peak/RMS ratio 
(i.e. crest factor) that may cause distortion or inter-modulation effects. 


According to Ralph's book, a 6-channel 6-FSK (i.e. six 6-FSK systems 
paralleled using similar bandwidth) outperforms this MIL-STD-188C 
modem. Sounds interesting? 


73's 


Johan, KC7WW 

From bart@wb6hqk.ampr.org Tue Dec 20 20:00:42 1994 

Return-Path: <wb6éhqk! bart@gatekeeper.ent-img.com> 

Received: from gatekeeper.ent-img.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrKGM3-Q000s6C; Tue, 20 Dec 94 20:00 CST 

Received: from wb6hqk by gatekeeper.ent-img.com with uucp 
(Smail3.1.28.1 #5) id mOrKG8p-00041HC; Tue, 20 Dec 94 17:46 PST 

Received: by wb6éhqk.ampr.org (Smail3.1.28.1 42) 
id mOxKFSd-O004bNC; Tue, 20 Dec 94 17:03 WET 

Message-Id: <mOrKFSd-QO004bNC@wb6hqk. ampr.org> 

From: bart@wb6éhqk.ampr.org (Bart Rowlett) 

Subject: please subscribe 

To: hfsig@tapr.org 

Date: Tue, 20 Dec 1994 17:03:23 -0800 (PST) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 11 


subscribe 


From shall@rain.org Tue Dec 20 22:14:13 1994 
Return-Path: <shall@rain.org> 
Received: from coyote.rain.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxKIRG-OO0014HC; Tue, 20 Dec 94 22:14 CST 
Received: by coyote.rain.org(4.1/SMI-RAIN) with id AAQ9238 
for hfsig@tapr.org on Tue, 20 Dec 94 20:10:26 PST 
Date: Tue, 20 Dec 1994 20:10:25 -0800 (PST) 
From: Stephen Hall <shall@rain.org> 
To: hfsig@tapr.org 
Cc: hfsig@tapr.org 
Subject: Re: [HFSIG:136] Re: Achieving regulation by bandwidth 
In-Reply-To: <199412200206.SAA03125@unix.ka9q.ampr.org> 
Message-Id: <Pine.SUN.3.90.941220200614 .7789C-100000@coyote.rain.org> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Greetings Phil, Steve here, WM6P. Have not seen you since my visit to 
Qualcomm. I recently left Harris Corp but may be able to get you in 
touch with some of the guys that developed the Harris serial and parallel 
tone HF modems. They seem to know as much as anyone at this point that I 
have run into. 


73, Steve 
From BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com Tue Dec 20 22:20:22 1994 
Return-Path: <BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com> 
Received: from hp.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxKIXD-O000sCC; Tue, 20 Dec 94 22:20 CST 
Received: from opnmail3.corp.hp.com by hp.com with SMTP 
(1.37.109.14/15.5+ECS 3.3) id AA146613616; Tue, 20 Dec 1994 20:20:16 -0800 
Received: from by opnmail3.corp.hp.com with SMTP 
(1.37.109.8/15.5+ECS 3.3) id AA24661; Tue, 20 Dec 1994 20:20:15 -0800 
From: BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com 
X-Openmail-Hops: 2 
Date: Tue, 20 Dec 94 20:20:00 -0800 
Message-Id: <"d0eqoS-000000000x" @MHS> 
In-Reply-To: <"B570F42212D(1)a(*«"@MHS> 
Subject: [HFSIG:145] Re: HF Modulation Modes 
To: hfsig@tapr.org 


Johan KC6WW said: 


>This is interesting - one question: did we overcome the need for 
>coherent detection, or does it matter? 


On the receiving end, I presume you would just run a DFT on the 
incoming sampled data which would output the frequency and phase 
of each carrier. It is effectively coherent detection, since 
the phase is known. 


Alan N1AL 

From k5yfw@k5yfw.ampr.org Tue Dec 20 23:59:07 1994 

Return-Path: <k5yfw@k5yfw.ampr.org> 

Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrKK30-Q001KEC; Tue, 20 Dec 94 23:58 CST 

Date: Tue, 20 Dec 94 23:18:59 CST 

Message-Id: <2378@k5yfw.ampr.org> 

From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW) 

Reply-To: k5yfw@sat.n5lyt.ampr.org 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:144] HF Modulation Modes 

In-Reply-To: Your message of Tue, 20 Dec 94 16:18 CST 

X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS) 


Gee Alan, kinda sounds like the 16 & 39 parallel tone modem formats in 
MIL-STD-188-110c. 16 or 39 parallel tones, with QPSK, inter-leaving and 
Reed-Soloman coding for FEC. In the 39 tone modem, a 40th tone has no 
modulation and is called the Doppler Tone. If phase shift is detected 
on it, the modem knows than inter-symbol interference due to multipath 
propagation is taking place. The baud rate on the 39 tone modem is less 
than 50 baud and the bandwidth of the signal is 3 KHz. The transmitted 
"data thruput rate (their terminology) is 2400 BPS. The actual 
transmitted bit rate is 3200-3600...I've forgotten and don't want to dig 
into my files tonight. The CLOVER II is a 4 parallel tone modem (and a 
few other things) and runs 850-900 BPS. 


Walt@home.2.nite 


In message <9412202217.AA06592@eagle.sr.hp.com> you write: 
I haven't posted to a list before, so let's see if this works... 


In all the discussion about the best modulation format for HF, I'm 

surprised nobody has mentioned OFDM. Oxthogonal frequency-division 
multiplex is proposed for Digital Audio Broadcasting and digital TV 
in Europe, although it is not so well known in the US. 


The idea is to split the signal up into a large number (like 128 or 
1024) equally-spaced carriers, each modulated at the same symbol rate. 
I believe the DAB standard proposes that each carrier be modulated 
with QPSK, but you can use any modulation in which each symbol can be 
represented by a phase and amplitude. That includes the many forms of 
QAM, PSK, PI/4 DQPSK, on-off keying, whatever. 


For example, If you use 128 carriers, the symbol rate is reduced by 

a factor of 128, greatly reducing the probability of inter-symbol 
interference due to multipath propagation. Adding forward error 
correction and time and frequency interleaving reduces the probability 
of bit errors due to selective fading on one or more carriers. 


> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> The reason the mode is called "orthogonal" FDM is that the carrier 
> frequency spacing is 1/symbol period, which theoretically eliminates 
> interference from all unwanted carriers. This is easiest to see in 
> the time domain. For a symbol rate of 1 symbol/s, the carriers will 
> be spaced 1 Hz apart. During each symbol period, the detector for 
> each carrier receives a certain number of RF cycles of the desired 
> carrier. During that same time period, each unwanted carrier has a 
> number of cycles that differ from the desired carrier by an integer. 
> Convolving two sine waves that differ by an integer number of cycles 
> gives zero result. 

> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


You could implement OFDM by building 128 RF oscillators, 128 I/Q 
modulators, and the associated controlling hardware. But there's a 
much simpler way, and here's the clever part of OFDM: 


I mentioned that the signal consists of a series of equally-spaced 
RF signals, each characterized by an amplitude and a phase. If you 
do an inverse DFT on that data, you come out with the time samples 
of the composite signal! At the kinds of data rates we are talking 
about, an inexpensive DSP would be plenty fast enough. For example, 
a 12.5 MHz ADSP21xx can do a 256-point DFT in 0.59 ms. So we're 
talking about a $10 DSP and a single I/Q modulator running at very 
low symbol rates. 


For example, 128 QPSK carriers spaced 7.5 Hz apart (7.5 baud) gives 
1920 bits per second within the 1 kHz bandwidth limit. The DSP 
has 1/7.5 = 133 ns to do all its calculations. 


The choice of modulation type for the carriers affects only the 


amplitude/phase list for each symbol. So it would be easy to 
change modulation types to respond to different propagation 
conditions, ala Clover. By including the capability to do various 
size FFTs, different symbol rates could be implemented using the 
same bit rate within the same bandwidth. i.e. use very slow 
symbol rates (large FFT) under fast Rayleigh fading conditions 

and faster symbol rates (small FFT) with slow flat fading. 


Alan Bloom N1AL 


VVVV VV VV VV 


> 

From k5yfw@k5yfw.ampr.org Tue Dec 20 23:59:12 1994 

Return-Path: <k5yfw@k5yfw.ampr.org> 

Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrKK3T-QOQOQOVAC; Tue, 20 Dec 94 23:57 CST 

Date: Tue, 20 Dec 94 23:39:45 CST 

Message-Id: <2381@k5yfw.ampr.org> 

From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW) 

Reply-To: k5yfw@sat.n5lyt.ampr.org 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:146] Re: HF Modulation Modes 

In-Reply-To: Your message of Tue, 20 Dec 94 18:27 CST 

X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS) 


In message <B5855F80B9A@frl.orst.edu> you write: 

[stuff deleted] 
I have some further specifications on its BER, but unfortunately not 
with me at the moment. Walt, K5YFW, could perhaps attest how these 
have been doing on the military HF nets. This is living proof that 
phase modulation is worth considering on HF. 

[stuff deleted] 


VVNV WV 


> 73's 


> Johan, KC7WW 


Do you "guys" remember all those "Sadamn" cartoons during Desert 
Shield/Storm? Well, bunches of them originated in Saudi. We would hook 
the RS-232 (1/0) of a FAX machine to a Harris MIL-STD-188-110c modem run 
the 39 tone mode and FAX them out to the troops at 2400 BPS using only 
100 watts (AN/URC-119 HF system by Harris). Data input was thru the 
aux. audio jack (a DB-9) and running USB. We would pass a page in just 
a couple of minutes. 


Ok, so how did the Patriot missile know where to "point" in the sky to 
lock onto a Skud? Easy, the AWACS caught the ground launch, snapped a 
video picture from the radar and sent the picture, with Lat/Long data, 
via HF radio and a MIL-STD-188-110c modem down the the Harris HF radio 
and MIL-STD modem in the Patriot missile battery and the battery pre- 
positioned its radar antennas and missile tubes in the correct part of 
the sky to intercept the Skud. And all this time you thought the 
Patriot missile was doing it all. Yep AWACS to Patriot in less than a 
minute. Did I mention digital encrypted voice on HF? Guess I'd better 


not on that one. 
Hello from Levenworth. 
73, 


Anonymous 

From BobH@eworld.com Wed Dec 21 06:23:25 1994 

Return-Path: <BobH@eworld.com> 

Received: from hpl.online.apple.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOrkKQ4g-QOQ00f£LC; Wed, 21 Dec 94 06:23 CST 

Received: by hp1.online.apple.com 
(1.38.193.5/16.2) id AA15759; Wed, 21 Dec 1994 04:23:20 -0800 

From: BobH@eworld.com 

X-Mailer: AOS Mailer 

Sender: "BobH" <BobH@eworld.com> 

Message-Id: <9412210423 .tn19172@eworld. com> 

To: hfsig@tapr.org 

Date: Wed, 21 Dec 94 04:23:15 PST 

Subject: Achieving regulation by bandwidth 


I'm glad someone mentioned the appropriateness of a modulation technique for 
"noisy, interference-prone" channels. Narrow-band co-channel interference 
(QRM) is getting my attention as the missing sun spots force more hf users 
into competition on lower and lower and fewer and fewer frequencies. 


Analyze your modulation scheme's BER in white noise and then analyze it again 
this time with a +30dB 850 shift 75 baud binary FSK signal in the middle of 
it. 


The commercial single tone modems waveshape spread to 3 khz and then use 
adaptive narrow band interference suppressers to notch out several jammers on 
the channel. The only energy to "shine" on the detector is the wanted signal. 


QRM is a good argument for relaxing the bandwidth limits for new digital 
modes ( in what at first seems to be a paradox but really isn't as others on 
this SIG and elsewhere have pointed out). We can co-exist with current 
user's: We notch them out; they power through us. Or our signal processing 
gain spreads them and de-spreads us, something like that. 


If we don't have the MIPS and the algorithms for the STANAG and the MIL-STD 
adaptively equalized single tone hf modems, I saw an alternative: 

"A chirp modem incorporating interference excision" IEE Proceedings Vol. 139, 
Aug 1992 . 

They chirp from 300-3000 Hz using a TMS320C25 and "recent work has increased 
the data rate to 600 bits/s". Looks easy, fun, robust and illegal! 


Bob 


From FORRERJ@frl.orst.edu Wed Dec 21 11:05:29 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxKURM-O000V1C; Wed, 21 Dec 94 11:03 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAOQO0187 for <hfsig@tapr.org>; Wed, 21 Dec 1994 
01:24:44 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Wed, 21 Dec 94 8:44:01 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 21 Dec 94 8:43:38 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 21 Dec 1994 08:43:35 PST8PDT 
Subject: Re: [HFSIG:149] Re: HF Modulation Modes 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <B68A31F1F55@frl.orst.edu> 
Alan Bloom, N1AL wrote: 


>On the receiving end, I presume you would just run a DFT on the 
>incoming sampled data which would output the frequency and phase 
>of each carrier. It is effectively coherent detection, since 
>the phase is known. 


That is good news Alan. After your post, I spent last night digging out 
all the stuff that I had on the MIL-STD-188 39-tone parallel modems, and 
what a surprize - now that I know a little better what to look for. 


The 39-tone system is, by definition, what you called ODFM. It comprizes 
39 tones, spaced to obtain orthogonal signaling, with each tone TDPSK 

(4 phase) modulated (I don't quite understand yet what this means? Anyone 
pse). Although very few manufacturers actually tell you how they do 

their demodulation, I found one reference to it: 128 point FFT! All these 
systems occupy a typical voice bandwidth channel and even when it operates 
at lower bit rates, never uses less bandwidth, but uses redundancy instead. 
The figures for BER for these 39-tone modems, as specified minimum 
performance specs (from MIL-STD-188-110 document), requires: 

1.8e%-4 at 30 dB S/N for 2400 bps, 2.7e%-6 also at 30 dB S/N for 1200 bps. 
At 75 bps 1.0e%-6 for 8 dB S/N. I think wwill agree that this is not 

bad. Keep in mind that all these BER merits relies heavily on coding, 

i.e. block or convolutional combined with interleaving. All the specs that 
I looked at also includes some form of tracking for doppler, i.e. +/- 75Hz, 
at a rate of 3.5 Hz/second. One small tidbit was that one manufacturer 
actually disclosed that an M68030 was used as a controller in conjunction 
with two M56002's. 


Does anyone have further references to such ODFM modulation schemes? 
I would be very interested to hear more. 


Thanks for all the excellent contributions - we are making good 
progress. 


73's 


Johan, KC7WW 


From larry@owrlakh.unbc.edu Wed Dec 21 11:15:44 1994 

Return-Path: <larry@owrlakh.unbc.edu> 

Received: from owrlakh.unbc.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxKUdU-OQOOOkAC; Wed, 21 Dec 94 11:15 CST 

Received: (from larry@localhost) by owrlakh.unbc.edu (8.6.9/8.6.9) id JAAQ8836 for 

hfsig@tapr.org; Wed, 21 Dec 1994 09:15:20 -0800 

From: Larry Gadallah <larry@owrlakh.unbc.edu> 

Message-Id: <199412211715. JAAQ8836@owrlakh.unbc.edu> 

Subject: Re: HF Modulation Modes 

To: hfsig@tapr.org 

Date: Wed, 21 Dec 1994 09:15:19 -0800 (PST) 

In-Reply-To: <9412202217.AA06592@eagle.sr.hp.com> from "Alan Bloom" at Dec 20, 94 

04:18:00 pm 

X-Mailer: ELM [version 2.4 PL23] 

MIME-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 

Content-Length: 1781 


In all the discussion about the best modulation format for HF, I'm 
surprised nobody has mentioned OFDM. Oxthogonal frequency-division 
multiplex is proposed for Digital Audio Broadcasting and digital TV 
in Europe, although it is not so well known in the US. 


The idea is to split the signal up into a large number (like 128 or 
1024) equally-spaced carriers, each modulated at the same symbol rate. 
I believe the DAB standard proposes that each carrier be modulated 
with QPSK, but you can use any modulation in which each symbol can be 
represented by a phase and amplitude. That includes the many forms of 
QAM, PSK, PI/4 DQPSK, on-off keying, whatever. 


VV VV VV VV VV VV OV 


Isn't this what Telebit does for its Packetized Ensemble Protocol (PEP) 
used for long haul high-speed landline modem connections? Some of my 
colleagues and I have occasionally wondered about using a couple of 
Telebits for HF modems, despite the obvious legal problems. 


I have also considered the idea that OFDM is a coarse grained form of 
spread spectrum, albeit with little spreading. Wouldn't it be nice 

to be able to spread a 1 kbps signal over a 3 khz bandwidth and thus 
provide some protection against interference and fades? How about 
feeding a 1 kbps data stream into a DSP and producing a 300 to 3300 
Hz DS spread spectrum signal that could be piped directly into the 


modulator of an HF rig. I guess there could be problems with modulator 
non-linearity. 


73, 
Larry Gadallah VE4TCP/VE6VQ Prince George, BC 
Internet: larry@owrlakh.unbc.edu TPC: (604) 964-1140 


ICBM: 53:51'38.4"N 122:44'25.8"W 
From rs@ife.ee.ethz.ch Wed Dec 21 13:18:55 1994 
Return-Path: <rs@ife.ee.ethz.ch> 
Received: from bernina.ethz.ch by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxKWwWr-O0018FC; Wed, 21 Dec 94 13:16 CST 
Received: from ife (actually ife-gw.ethz.ch) by bernina.ethz.ch 
with SMTP inbound; Wed, 21 Dec 1994 20:15:25 +0100 
From: Rolf Sommerhalder <rs@ife.ee.ethz.ch> 
Message-Id: <9412211915.AA21592@ife> 
Received: from ife.ee.ethz.ch (gillespie) by ife.ee.ethz.ch id AA21592; 
Wed, 21 Dec 1994 20:15:24 +0100 
Received: by gillespie.ethz.ch; Wed, 21 Dec 94 20:15:23 +0100 
Subject: Re: [HFSIG:153] Re: HF Modulation Modes 
To: hfsig@tapr.org 
Date: Wed, 21 Dec 94 20:15:23 MET 
In-Reply-To: <B68A31F1F55@frl.orst.edu>; from "Johan Forrer FL" at Dec 21, 94 
11:10 am 
content-length: 1082 


> ... One small tidbit was that one manufacturer 
> actually disclosed that an M68030 was used as a controller in conjunction 
> with two M56002's. 


Recently, I had the chance to have a view into a pair of pre-production MIL- 
STD-188 

parallel- (and serial-) tone HF-modems (the kind of olive-green painted brand and 
price-tag). 

The job is done by two ADSP-2100 16-bit fixed point DSPs from Analog Devices. 
This job can probably done soon by a single DSP like a 80 or 100 MHz TMS320C50 or 
similar. 


73s, 
Rolf 


ee a a 


Rolf Sommerhalder 
Swiss Federal Institute of Technology (ETH) home address: 


Electronics Laboratory ETZ H60.1 c/o Rindlisbacher 
Gloriastrasse 35 Wermatswilerstrasse 96 
8092 Zurich / Switzerland 8610 Uster / Switzerland 


Voice +41 1 632 76 40 (or 632 51 53) Voice +41 1 941 59 28 


Fax +41 1 632 12 10 AX.25 HB9CWP @ HB90S 
E-Mail rolf.sommerhalder@ife.ee.ethz.ch Swiss Disaster Relief HBK81 


From BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com Wed Dec 21 13:48:46 1994 
Return-Path: <BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com> 
Received: from hp.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxKX1c-O0001A1C; Wed, 21 Dec 94 13:48 CST 
Received: from opnmail3.corp.hp.com by hp.com with SMTP 
(1.37.109.14/15.5+ECS 3.3) id AA197729310; Wed, 21 Dec 1994 11:48:30 -0800 
Received: from by opnmail3.corp.hp.com with SMTP 
(1.37.109.8/15.5+ECS 3.3) id AA11034; Wed, 21 Dec 1994 11:48:29 -0800 
From: BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com 
X-Openmail-Hops: 2 
Date: Wed, 21 Dec 94 11:48:00 -0800 
Message-Id: <d0eqY8Z000000000@MHS> 
Subject: Re: HF Modulation Modes 
To: hfsig@tapr.org 


Walt@home.2.nite said: 


>Gee Alan, kinda sounds like the 16 and 39 parallel tone modem formats in 
>MIS-STD-188-110c. 


Kinda. Although with only 16 or 39 tones, using a FFT/IFFT is not very 
efficient, since you don't have 24N tones. With fewer tones, you need 
a higher symbol rate to get a desired bit rate, which would require 
more DSP horsepower. As Bob said: 


BobH said: 


>If we don't have the MIPS and the algorithms for the STANAG and the 
>MIL-STD adaptively equalized single tone hf modems... 


The advantage of OFDM is the computational efficiency due to using the 
FFT. Equalization is easy: Just adjust the amplitude and phase of 
each of the carriers in the frequency domain before doing the IDFT. 


Larry Gadallah said: 


>I have also considered the idea that OFDM is a coarse grained form of 
>spread spectrum, albeit with little spreading. 


It's not really spread, since the total bandwidth is about the same 
as a Single carrier modulated with the same bit rate. 


By the way, on the subject of bandwidth, there is no need for 
pre-modulation filtering of the transmitted signal (other than the 
standard DAC anti-aliasing filter). That's because each carrier has 
such a low baud rate that even with unfiltered square waveforms 

the sinx/x frequency rolloff is fast enough to give an almost-square 
frequency spectrum for the composite signal. 


Alan 


From karn@unix.ka9q.ampr.org Wed Dec 21 17:27:44 1994 

Return-Path: <karn@unix.ka9q.ampr.org> 

Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrKaRW-OOO1MLC; Wed, 21 Dec 94 17:27 CST 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id PAAQ5236; Wed, 

21 Dec 1994 15:29:12 -0800 

Date: Wed, 21 Dec 1994 15:29:12 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199412212329 .PAAQ5236@unix.ka9q.ampr.org> 

To: FORRERJ@fxr1.orst.edu 

CC: hfsig@tapr.org 

In-reply-to: <B51ED1660BE@frl.orst.edu> (FORRERJ@fr1l.orst.edu) 

Subject: Re: [HFSIG:141] Re: Achieving regulation by bandwidth 

Reply-To: karn@qualcomm.com 


Johan, 


This stuff is well covered in communications theory textbooks, but here's 
a shot. 


Entropy is a measure of information content. It's also a measure of 
uncertainty. Receiving a bit that you always know will be a "1" ora 
"Q@" carries no real information; its entropy is 0 bits. A bit that is 
(to you) completely unpredictable and has a 50-50 chance of being 
either a 1 or a © carries 1 bit of entropy. A bit that is skewed, i.e., 
has some uncertainty to it but can be predicted with better than chance 
odds has entropy somewhere between © and 1 bit. 


Compression algorithms increase entropy in a data stream by removing 
redundancy. An ideal compression algorithm produces output with 1 bit 


of entropy per compressed data bit. 


Channel capacity on an additive white gaussian noise channel is 
defined by Shannon's famous formula 


C = B log2(1 + S/N) 


where C = channel capacity in bits/sec ("real" bits, with 1 bit entropy each) 
B = channel bandwidth in Hz 
S = received signal power in watts 
N = received noise power in watts 


The important thing to note about the Shannon equation is the 
fundamental tradeoff between bandwidth and S/N. The wider the 
bandwidth, the lower the S/N required to maintain a constant 
capacity. And the narrow the bandwidth, the higher the S/N required. 


Since N also depends on bandwidth it's usually more instructive to 
consider Eb/NO instead of S/N: 


Eb/NO = (S/R) / (N/B) = S/N * B/R 


where Eb = received energy per bit in joules 


NO = received noise spectral density in watts/Hz. 
R = data rate in bits/sec 


Note that Eb/NO is independent of signal bandwidth. Eb/NO is still 
dimensionless (just like S/N) since watts/Hz also has units of 
joules. It is equal to S/N only for the case where the modulation 
bandwidth in Hz equals the data rate in bits/sec. Eb/NO is now 
universally used in describing the performance of a modem against 
white noise. 


If you substitute this into Shannon's formula and solve for Eb/NO you 
get 


Eb/NO = B/R * (24(R/B) - 1) 


This tells you the absolute minimum Eb/NO that any modem must have 
when operating at a specified data rate R and bandwidth B. Real modems 
will of course require more. In the limit of B/R = infinity, i.e., 
infinite bandwidth for a finite data rate, Eb/NO = -1.6 dB, the famous 
Shannon limit. Note, though, that this applies ONLY to infinite 
bandwidth. For finite values of R/B, the required Eb/NO is 

higher. E.g., for R/B of unity, the minimum Eb/NO is 0 dB. For an R/B 
of about 4 bit/sec/Hz, the minimum Eb/NO is about +6 dB. If you make 
R/B less than 1, eg, by adding FEC, the minimum required Eb/NO drops 
below 0 dB. For a rate 1/2 code, this is about -.8 dB. Real, 
implementable codes at this rate can get down to about +2.5 dB; I've 
done this with soft decision sequential decoding. 


Note that a "bit" represented by Eb is a real user data bit, NOT a 
coded channel symbol. That's another reason to use Eb/NO: it takes FEC 
into account. FEC provides a real power gain in that I can use fewer 
transmitter watts to send a given number of user data bits per second. 
But there's no free lunch; my transmitter power savings come at the 
expense of additional bandwidth. FEC simply allows me to play with the 
terms in the Shannon equation and to come more closely to its limits; 
it doesn't allow me to violate it. 


Power efficiency has traditionally been considered important only in 
situations like deep space communications where transmitter power is 
an absolute premium. But it's now getting quite a bit of attention 
even where RF power is relatively cheap: the shared terrestrial 
channel. That's because a modulation method that requires relatively 
low Eb/NO is not only more tolerant of interference (considering 
interference to be part of the noise) but it also generates less 
interference to others since it needs less power to communicate. 


This is a win-win approach much like reducing weight in a car: the 
lighter you make the car frame, the lighter the engine you need to 
move it, which means an even lighter frame to carry the weight of the 
engine, which means an even lighter engine, and so on. 


It turns out that at least in cellular mobile communications, the 
savings from reduced interference and increased interference tolerance 


more than make up for the extra bandwidth required. This is the basis 
of the CDMA spread spectrum stuff we've been developing at Qualcomm. 


I'm convinced that same principles apply to xany*x shared, interference 
limited RF environment, including HF. John Costas said as much when he 
wrote his famous paper, "Poisson, Shannon and the Radio Amateur" that 
appeared in the Proceedings of the IRE, December 1959. (It has been 
reprinted in many places, such as the IEEE book "Multiple Access 
Communications", edited by Norman Abramson, ISBN 0-87942-292-0.) 


Phil 

From karn@unix.ka9q.ampr.org Thu Dec 22 03:58:13 1994 

Return-Path: <karn@unix.ka9q.ampr.org> 

Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrKkHg-QQOQODkC; Thu, 22 Dec 94 03:58 CST 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id BAAQ5620; Thu, 

22 Dec 1994 01:59:58 -0800 

Date: Thu, 22 Dec 1994 01:59:58 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199412220959 .BAAQ5620@unix.ka9q.ampr.org> 

To: FORRERJ@fxr1.orst.edu 

CC: hfsig@tapr.org 

In-reply-to: <B570F42212D@frl.orst.edu> (FORRERJ@fr1.orst.edu) 

Subject: Re: [HFSIG:145] Re: HF Modulation Modes 

Reply-To: karn@qualcomm.com 


>This is interesting - one question: did we overcome the need for 
>coherent detection, or does it matter? 


>From briefly browsing the MIL specs, it looks like they dedicate one 
of the carriers to serve as an unmodulated phase and frequency 
reference for the others. 


Qualcomm CDMA does something similar on the forward (base->mobile) 
link. There's a spread but otherwise unmodulated component called the 
pilot that is always present. It's several dB stronger than the 
traffic channels. The mobiles use it as a timing, phasing and 
frequency reference for everything else they do. This works well in 
our system because a single pilot can be shared by all of the channels 
in the system. The reverse link has no pilot, so we use a form of 
64-ary orthogonal modulation instead to make up most of the loss from 
noncoherent demodulation. 


Phil 

From karn@unix.ka9q.ampr.org Thu Dec 22 04:22:44 1994 

Return-Path: <karn@unix.ka9q.ampr.org> 

Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxKk£P-OOOOLNC; Thu, 22 Dec 94 04:22 CST 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id CAAQ5738; Thu, 

22 Dec 1994 02:18:15 -0800 

Date: Thu, 22 Dec 1994 02:18:15 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199412221018.CAAQ5738@unix.ka9q.ampr.org> 


To: BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com 

CC: hfsig@tapr.org 

Reply-To: karn@qualcomm.com 

In-reply-to: <"d0eqoS-000000000*«"@MHS> (BLOOM_ALAN/HP5300_RO@opnmail3.corp.hp.com) 
Subject: Re: [HFSIG:149] Re: HF Modulation Modes 


>On the receiving end, I presume you would just run a DFT on the 
>incoming sampled data which would output the frequency and phase 
>of each carrier. It is effectively coherent detection, since 
>the phase is known. 


Not necessarily. Just because you can measure the received phase 
doesn't imply you know what phase was sent. But if you dedicated one 
of the channels to be an unmodulated phase reference, then you could 
probably use this to determine the transmitted phase in the other 
channels, assuming that the channel isn't too dispersive. 


Phil 


From karn@unix.ka9q.ampr.org Thu Dec 22 04:48:48 1994 

Return-Path: <karn@unix.ka9q.ampr.org> 

Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrKl4d-Q000YIC; Thu, 22 Dec 94 04:48 CST 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id CAAQ5769; Thu, 

22 Dec 1994 02:49:23 -0800 

Date: Thu, 22 Dec 1994 02:49:23 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199412221049.CAAQ5769@unix.ka9q.ampr.org> 

To: k5yfwe@k5yfw.ampr.org 

CC: hfsig@tapr.org 

Reply-To: karn@qualcomm.com 

In-reply-to: <2381@k5yfw.ampr.org> 

Subject: Re: [HFSIG:151] Re: HF Modulation Modes 


Hmm, MIL-STD-188-110C...is that anything like MIL-STD-188-110A? I just 
ran off a bunch of copies of the latter for the people who requested 
them, and now I wonder if I didn't have the latest revision. The date 
on the -110A version is 30 September 1991, which superseded -110 dated 
15 November 1980. 


If -110A didn't become active until late 1991, after the Gulf War was 
over, then how could you have used -110C modems? From looking at the 
standard it sure does xseemx like the same thing; there's a 16 tone 
mode and a 39 tone mode. 


By the way, for anyone interested in actually implementing this spec, 
I note that it specifies a rate 1/2 K=7 convolutional FEC. Several 
months ago I wrote and debugged a fast soft-decision Viterbi decoder 
for this particular code as it's a widely used standard (e.g., the 
Voyager spacecraft). 


After considerable cycle bumming my decoder runs at 41 kb/s on a 66 
Mhz 486 (32-bit protected mode, GCC 2.5.8 with full optimization). 


Should be plenty fast for this application. I'd be happy to make it 
available. 


Phil 


From karn@unix.ka9q.ampr.org Thu Dec 22 05:15:40 1994 

Return-Path: <karn@unix.ka9q.ampr.org> 

Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrK1Tp-Q00OhoC; Thu, 22 Dec 94 05:14 CST 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id DAAQ5783; Thu, 

22 Dec 1994 03:15:12 -0800 

Date: Thu, 22 Dec 1994 03:15:12 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199412221115 . DAAQ5783@unix.ka9q.ampr.org> 

To: k5yfwe@k5yfw.ampr.org 

CC: hfsig@tapr.org 

In-reply-to: <2381@k5yfw.ampr.org> 

Subject: Re: [HFSIG:151] Re: HF Modulation Modes 


>Ok, so how did the Patriot missile know where to "point" in the sky to 
>lock onto a Skud? Easy, the AWACS caught the ground launch, snapped a 
>video picture from the radar and sent the picture, with Lat/Long data, 
>via HF radio and a MIL-STD-188-110c modem down the the Harris HF radio 
>and MIL-STD modem in the Patriot missile battery and the battery pre- 


Hmm, considering that the more sober studies made after the war 
concluded that there was no hard evidence that even ONE SCUD missile 
had been successfully engaged and destroyed, perhaps we should 
consider a different HF modem technology? 


=) 


More seriously, I did get a chance to leaf through the Ralphs book 

this afternoon in the UCSD library. I hadn't renewed my library card, 

so I had to get the gist of it in the 45 min remaining before the 

library closed. (Bad planning, I know). I also noted the comparisons 
between the Piccolo-style MFSK modems used by the British foreign service 
and the multicarrier PSK systems that seem to be favored by the US 
military. The Eb/NO curves were significantly better for Piccolo. The 
discussion commented that the multicarrier PSK systems did require much 
better channel conditions. 


This matches my understanding of the problem. Now it is true that real 
HF channels are not always as bad as the pure Rayleigh model would 
suggest. The fading process is usually bandlimited, limiting the fade 
rate, and there are usually only a small number (often 2) of multipath 
components. In this situation you xcanx get away with phase 
modulation. 


But if you really want to get the most out of a really lousy channel 
with the least power, I think the author is right - MFSK with 
noncoherent detection is the way to go. Another part of the book 
described some interference tests they did. One involved running 


Piccolo signals "underneath" BBC program material. The Piccolo signal 
could still be copied even when it was so weak as to be only a 
slightly noticeable background behind the audio program. 


Phil 

From BobH@eworld.com Thu Dec 22 06:18:05 1994 

Return-Path: <BobH@eworld.com> 

Received: from hpl.online.apple.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrkKmT2-0000jeC; Thu, 22 Dec 94 06:18 CST 

Received: by hp1.online.apple.com 
(1.38.193.5/16.2) id AA19890; Thu, 22 Dec 1994 04:17:57 -0800 

From: BobH@eworld.com 

X-Mailer: AOS Mailer 

Sender: "BobH" <BobH@eworld.com> 

Message-Id: <9412220417 .tn32612@eworld.com> 

To: hfsig@tapr.org 

Date: Thu, 22 Dec 94 04:17:50 PST 

Subject: HF Modulation Modes 


I just got my "QEX" for December: 
STANAG 4285 kicks butt! 


Which leads to one question (of many) 
to which I'm sure no simple answer 
exists: 


Which code is "better" for the hf channel: 

> A convolutional code with interleaver. 
or 

> A R-S block code with soft decision. 


2??? 
Or is that even the right question? 


If we only had a channel simulator. 


bob wm6h 


From FORRERIJ@frl.orst.edu Thu Dec 22 11:05:16 1994 
Return-Path: <FORRERJ@fr1l.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrkKqwz-00014jC; Thu, 22 Dec 94 11:05 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAQ4225 for <hfsig@tapr.org>; Thu, 22 Dec 1994 
01:44:42 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Thu, 22 Dec 94 9:04:06 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 22 Dec 94 9:03:52 
PST8PDT 
From: "Johan Forrer 


FL" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 22 Dec 1994 09:03:49 PST8PDT 

Subject: Re: [HFSIG:101] Ideas for HF modulation and coding 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <B80FA331EF6@frl.orst.edu> 
Phil, 


Thanks much for the brief note on Shannon - it always is a 
good reality check to keep those principles in mind. 


OK - I am ready to start playing with some of these great ideas - perhaps 
we can start looking into some of the practical details now. 

It would not be difficult to simulate the multi-tone signals ina 

C program, and then play with the different ideas on demodulation. 


It appears there are two ideas put forward: 


1) (ODFM) n-parallel carriers with orthoganal signaling. All carriers 

are always present. Demodulation is performed by FFT's. It is obvious that 
the choice of the FFT size and sample rate have to just right otherwise we 
will end up with an odd distribution of our carriers over the 
frequency/phase bins. After this choice have been made, how do I use this 
I/Q recovered data? I have some wild ideas, but would like to obtain 
further input first. 


2) (Phil's method based on Welch functions) n-parallel tones with orthoganal 
signaling. Only a small subset of carriers are present at a time - the 
different subset is selected from a Hamadard matrix. In a sense, 

Piccolo may be considered a special case of this idea, where only one 
carrier is sent at a time from a set of m-carriers. Phil mentioned that FHT 
(is that for fast hadamard transform?) is used to perform demodulation. How 
about telling us a bit more about how to implement this one Phil. 


73's 
Johan, KC7WW 


From k5yfw@sacdm10.kelly.af.mil Thu Dec 22 11:05:24 1994 
Return-Path: <k5yfw@sacdm10.kelly.af.mil> 
Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrkKqx6-0000xnC; Thu, 22 Dec 94 11:05 CST 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOxrKqtF-00024cC; Thu, 22 Dec 94 11:01 CST 
Message-Id: <mOxrKqtF-00024cC@sacdm10.kelly.af.mil> 
Date: Thu, 22 Dec 94 11:01:21 -0600 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Which Modem 
To: hfsig@tapr.org 


Cc: tbruns@datarace.com 
The question has been ask "which modem?" 
I think the answer is, we don't know at this point in time. 


While members of this group are gathering information about different 
modems and techniques, they are also gathering information about a how 
to create an HF channel simulator. Once a simulator is developed, we 
can evaluate different modems and techniques. The group can then 
begin to evaluate different modems and modem techniques. 


I wish we were already to release code for a soundcard that would make 
2400 BPS possible on HF. But, most/all of us have to put beans on the 
table for ourselves and/or family. I keep telling myself this x*isx* a 
hobby. 


When it comes time to release code for on-the-air testing, and 
before, we are going to need an informed member base to carry our 
torch to the rest of the ham world...this isn't going to be easy and 
we will have a great amount of resistance. But, we must be ready, 
informed and ready to fight. 


One thing to keep in mind is that *xwhen* we are successful, we will 
be giving the ham radio world a wonderful new "toy" and make robust, 
high speed data transmissions on HF available at an affordable price 
to the entire world. 


73 & Happy Holidays, 


Walt/K5YFW 

From k5yfw@sacdm10.kelly.af.mil Thu Dec 22 11:42:00 1994 

Return-Path: <k5yfw@sacdm10.kelly.af.mil> 

Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp 
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Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOrKrSm-Q002ANC; Thu, 22 Dec 94 11:38 CST 

Message-Id: <mOxrkKrSm-Q002ANC@sacdm10.kelly.af.mil> 

Date: Thu, 22 Dec 94 11:38:03 -0600 

From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 

Subject: Re: [HFSIG:161] Re: HF Modulation Modes 

To: hfsig@tapr.org 

Cc: tbruns@datarace.com 

X-orig-date: Thu, 22 Dec 94 05:20 CST 

X-orig-from: Phil Karn <karn@unix.ka9q.ampr.org> 

X-orig-message-ID: <199412221115 .DAAQ5783@unix.ka9q.ampr.org> 


In your message of 22 Dec 1994 at 0520 CST, you write: 

> >0k, so how did the Patriot missile know where to "point" in the sky to 
> >lock onto a SCUD? Easy, the AWACS caught the ground launch, 

snapped a 

> >video picture from the radar and sent the picture, with Lat/Long data, 
> >via HF radio and a MIL-STD-188-110c modem down the the Harris HF radio 


VV VV VV VV 


VV VV VV VV VV VV VV VV VV VV VV VV VV 


>and MIL-STD modem in the Patriot missile battery and the battery pre- 


Hmm, considering that the more sober studies made after the war 
concluded that there was no hard evidence that even ONE SCUD missile 
had been successfully engaged and destroyed, perhaps we should 
consider a different HF modem technology? 


oe 


The video taken by my troops from atop of the villas in Eskan 
Village just outside of the Saudi Capital (50,000 + U.S. 
troops lived in Eskan Village) indicated that there were 
direct hits. Whether they destroyed, deflected or made a 
difference in the targeting is an opinion. 


The data provided by the HF to the Patriot sites only helped 
the site point their radar antennas in the right part of the 
sky, it had nothing to do with the radar acquisition/lockon 

of the SCUD or the capability of the missile system destroying 
the target. A Patriot Missile Battery cannot "look" at the 
entire "sky" in front of it, just one quadrant. 


More seriously, I did get a chance to leaf through the Ralphs book 
this afternoon in the UCSD library. I hadn't renewed my library card, 
so I had to get the gist of it in the 45 min remaining before the 
library closed. (Bad planning, I know). I also noted the comparisons 


between the Piccolo-style MFSK modems used by the British foreign service 


and the multicarrier PSK systems that seem to be favored by the US 
military. The Eb/NO curves were significantly better for Piccolo. The 
discussion commented that the multicarrier PSK systems did require much 
better channel conditions. 


This matches my understanding of the problem. Now it is true that real 
HF channels are not always as bad as the pure Rayleigh model would 
suggest. The fading process is usually bandlimited, limiting the fade 
rate, and there are usually only a small number (often 2) of multipath 
components. In this situation you xcanx get away with phase 
modulation. 


But if you really want to get the most out of a really lousy channel 
with the least power, I think the author is right - MFSK with 
noncoherent detection is the way to go. Another part of the book 
described some interference tests they did. One involved running 
Piccolo signals "underneath" BBC program material. The Piccolo signal 
could still be copied even when it was so weak as to be only a 
slightly noticeable background behind the audio program. 


Do we want to design a modem for the worse-case scenario or 
can we live with one that can get data thru on the worst 
channel part of the time. I have a pick-up without 4 wheel 


drive...there are at times places I can't drive...so I don't 
drive there until conditions are better. There are places 
where I can drive without 4 wheel drive that my Geo Metro can 
never go. Should I have 4 wheel drive? Do we need a modem 
that can get thru even the worst conditions or can we settle 
for something less. Are we purist or realists? 


Walt (dba k5y£w) 

From k5yfw@sacdm10.kelly.af.mil Thu Dec 22 12:21:31 1994 

Return-Path: <k5yfw@sacdm10.kelly.af.mil> 

Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxKs81-O0001RCC; Thu, 22 Dec 94 12:21 CST 

Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOrKs5B-000295C; Thu, 22 Dec 94 12:17 CST 

Message-Id: <mO0xrKs5B-000295C@sacdm10.kelly.af.mil> 

Date: Thu, 22 Dec 94 12:17:44 -0600 

From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 

Subject: Re: [HFSIG:160] Re: HF Modulation Modes 

To: hfsig@tapr.org 

X-orig-date: Thu, 22 Dec 94 04:56 CST 

X-orig-from: Phil Karn <karn@unix.ka9q.ampr.org> 

X-orig-message-ID: <199412221049.CAA05769@unix.ka9q.ampr.org> 


Phil, 


In your message of 22 Dec 1994 at 0456 CST, you write: 

Hmm, MIL-STD-188-110C...is that anything like MIL-STD-188-110A? I just 
ran off a bunch of copies of the latter for the people who requested 
them, and now I wonder if I didn't have the latest revision. The date 
on the -110A version is 30 September 1991, which superseded -110 dated 
15 November 1980. 


If -110A didn't become active until late 1991, after the Gulf War was 
over, then how could you have used -110C modems? From looking at the 
Standard it sure does xseemx like the same thing; there's a 16 tone 
mode and a 39 tone mode. 


VV VVVV VV VV 


Make that 110Xb, The appendix(?) for HF modems in the copy I have 
shows "b" for the 39 tone modem and "c" for the serial tone Harris 
modem. I don't have the complete MIL-STD, just the part on the 
modems...and that was given to me by the Harris RF Comm. 1Div. 


I'm glad someone is keeping me straight and honest, my XYL, WB5WXY, 
has failed at that task for the last 30 years. 


Walt 

From k5yfw@sacdm10.kelly.af.mil Thu Dec 22 12:58:09 1994 

Return-Path: <k5yfw@sacdm10.kelly.af.mil> 

Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxKsiE-00010rC; Thu, 22 Dec 94 12:58 CST 

Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOrKsWx-000295C; Thu, 22 Dec 94 12:46 CST 

Message-Id: <mOxrKsWx-000295C@sacdm10.kelly.af.mil> 


Date: Thu, 22 Dec 94 12:46:27 -0600 

From: k5yfw@sacdm10.kelly.af£.mil (WALT DUBOSE - K5YFW) 
Subject: Frederick Electronics Modem 

To: hfsig@tapr.org 

Cc: tbruns@datarace.com 


High Performance Data Modem 


SFA DataComm, Inc. 
Frederick Electronics 

7450 New Technology Way, 

P.O. Box 502 

Frederick, MD 21701 

(301) 662-5901 


Model 1102 NSN 5895-66-136-4191 ($7,500 U.S.) 


Capable of Tx and RX up to 2400 BPS in a standard 3 KHz ssb HF radio 
channel...meets Mil. Standard 188-110A 


3.47"H x 17"W x 16"D (19" Rack mounting) Approx. 12 lbs 
....Convolutional coding with soft decision Viterbi decoding.... 
....Interleaving... 

... User friendly interface...movement between windows... 
Additional planned capabilities: 


16 tone DPSK per MIL-STD-188-110a 

39 tone DPSK per MIL-STD-188-110a 

NATO mode IAW STANAG 4285 (3600 BPS) 

16 channel VFT mode (R.39) 

From k5yfw Thu Dec 22 14:17:25 1994 

Return-Path: <k5yfw@sacdm10.kelly.af.mil> 

Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxKtww-00011sC; Thu, 22 Dec 94 14:17 CST 

Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOrKttM-Q002AmC; Thu, 22 Dec 94 14:13 CST 

Resent-Message-Id: <mOrkKttM-0002AmC@sacdm10.kelly.af.mil> 

Resent-date: Thu, 22 Dec 94 14:13:40 -0600 

Resent-from: k5yfw (WALT DUBOSE - K5YFW) 

Subject: Fw: Oops, I lied Again 

Resent-to: hfsig@tapr.org 

Date: Thu, 22 Dec 94 12:28:47 -0600 

From: k5yfw (WALT DUBOSE - K5YFW) 

Subject: Oops, I lied Again 

To: hfsig 


Oops, I lied again. The copy of the part MIL-STD-188-110 that I 
have says: 


MIL-STD-188-110 
NOTICE 2 
4 November 1988 


APPENDIX B, 16-TONE DIFFERENTIAL PHASE-SHIFT KEYING (DPSK) MODE 
APPENDIX C, 39-TONE MODE 


Walt 

From jmorriso@bogomips.ee.ubc.ca Fri Dec 23 12:51:37 1994 

Return-Path: <jmorriso@bogomips.ee.ubc.ca> 

Received: from bogomips.ee.ubc.ca by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxLEzS-0000hSC; Fri, 23 Dec 94 12:45 CST 

Received: by bogomips.ee.ubc.ca (Linux Smail3.1.29.1 48) 
id mOrLExU-0004giC; Fri, 23 Dec 94 10:43 PST 

Message-Id: <mOxrLExU-0004giC@bogomips.ee.ubc.ca> 

From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison) 

Subject: Re: [HFSIG:161] Re: HF Modulation Modes 

To: hfsig@tapr.org 

Date: Fri, 23 Dec 1994 10:43:19 -0800 (PST) 

In-Reply-To: <199412221115 .DAAQ5783@unix.ka9q.ampr.org> from "Phil Karn" at Dec 

22, 94 05:20:00 am 

X-Linux: watch for Linux '94 aka "Helsinki" 

X-Bogomips: 33.55 

X-Mailer: ELM [version 2.4 PL22] 

Content-Type: text 

Content-Length: 1153 


But if you really want to get the most out of a really lousy channel 
with the least power, I think the author is right - MFSK with 
noncoherent detection is the way to go. Another part of the book 
described some interference tests they did. One involved running 
Piccolo signals "underneath" BBC program material. The Piccolo signal 
could still be copied even when it was so weak as to be only a 
slightly noticeable background behind the audio program. 


VV VVV VV 


This isn't related to HF, but: would some modulation like Piccolo (I 
think I missed the description for that) be applicable to sending a 
data stream over a 2m or 70cm narrow-band FM voice radio? And 
preferably through a voice repeater as well. Speed would be about 50 
bps or so, just enough to send your callsign or a very short message 
when you key up the radio. 


BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM -- 
jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org 


From 70730.3472@compuserve.com Mon Dec 26 18:57:05 1994 


Return-Path: <70730.3472@compuserve.com> 

Received: from arl-img-1.compuserve.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrMP1X-0001j8C; Mon, 26 Dec 94 18:27 CST 

Received: by arl-img-1.compuserve.com (8.6.9/5.940406sam) 
id SAA12850; Mon, 26 Dec 1994 18:26:33 -0500 

Date: 26 Dec 94 18:25:39 EST 

From: Johan Forrer <70730.3472@compuserve.com> 

To: HFSIG <HFSIG@tapr.org> 

Subject: HF modulation 

Message-ID: <941226232538_70730.3472_CHK57-1@CompuServe. COM> 


Hi, 


As a way to learn more about how OFDM works for the 

39-tone MIL-STD-188 parallel modem, I wrote a C program that simulates 

39 parallel tones and combines them into a single output signal. The 

program then continues by modulating (DQPSK) each of these tones, using 

a simple binary pattern, i.e., 00 -> 01 -> 10 -> 11 (remember these 

are di-bits). This gives an effective raw rate of 2*39*56.25 = 4387.5 bps (56.25 
baud for each of the 39 channels) using a 3 kHz voice channel. Although I have 
not explored further aspects as yet, several transmission speeds ranging form 
75 - 2400 bps are possible by using some of the channels for redundancy. 
Error-correction coding is 

futher included that trades off between these bit rate and robustness. 


The program then continues the demodulation process by capturing 128 

data points and performing an FFT. This produces 64 positive frequencies 

of which only 39 are used - the remainder are disregarded or treated as 

guard bands - as would be required when such a system are to be used with 

a voice-grade IF filter. Shown in Table 1, below, are the recovered I and Q data 


for four channels, i.e., the first four channels of 39. It is evident that, with 
proper bit synchronization (which is fairly well documented for the MIL-STD 
modems), things seem to work out remarkably well. 


I also did capture the simulated output waveform and was quite concerned 
after inspecting the plot - the presence of large spikes of significant 
magnitude (in some cases, some 10-15 dB over the RMS value). This 

situation will certainly introduce data errors if not addressed. It should be 
stressed 

that such a signal will sound like a noise burst - it has little or no melody 
associated with 

it, except for the bit synchronizing pre-ambles. 


It ir my opinion, that after this initial analysis, that such a scheme may be 
quite doable on our present hardware. I have no doubt that, if signal synthesis 
and fast 

Fourier transform are performed on the DSP side, there should be plenty of 
computing power in a modest PC to run the remainder of such a modem, even 
considering the computing demands for error coding. 


Hope you all enjoyed the holiday season. Trust that 1995 will hold 
the best in health peace for you. 


73's 


Johan, KC7WW 


Table 1. 


An evaluation of the MIL-STD-188 modem using OFDM. 


BAUD # I Q Freq Real Imag <- appears swapped 
1 0 0 675.00 45.25 -45.25 
2 0 1 675.00 -45.26 45.24 
3 1 0 675.00 45.28 -45.23 
4 1 1 675.00 -45.31 45.20 
1 01 731.25 -45.25 45.25 
2 1 0 731.25 45.26 -45.24 
3 1 1 731.25 -45.22 -45.27 
4 0 0 731.25 45.23 45.24 
1 1 0 787.50 45.25 -45.25 
2 1 1 787.50 -45.24 -45.26 
3 0 0 787.50 45.24 45.28 
4 QQ 1 787.50 -45.30 45.22 
1 1 1 843.75 -45.25 -45.25 
2 0 0 843.75 45.24 45.26 
3 0 1 843.75 -45.25 45.23 
4 1 0 843.75 45.20 -45.31 


KC7WW, Dec 26, 1994 


From karn@qualcomm.com Mon Dec 26 19:00:03 1994 

Return-Path: <karn@qualcomm. com> 

Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxMQGf-O000uhC; Mon, 26 Dec 94 19:00 CST 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id RAA18816; 

Mon, 26 Dec 1994 17:01:51 -0800 

Date: Mon, 26 Dec 1994 17:01:51 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199412270101.RAA18816@servo.qualcomm. com> 

To: hfsig@tapr.org 

Subject: copies of MIL-STD-188-110A 


As I mentioned a week or so ago, I've run off four paper copies of 
MIL-STD-188-110A, dated 30 September 1991. 


I've also printed MIL-STD-203-1A, "Interoperability and Performance 
Standards for Tactical Digital Information Link (TADIL) A", 8 January 1988, 


and MIL-STD-188-203-3, "Subsystem Design and Engineering Stadards for 
Tactical Digital Information Link (TADIL) C", 5 October 1983. These two 
standards seem to discuss earlier multitone modems, perhaps related to 
110A. 


All standards are completely unclassified and marked "Approved for Public 
Release; distribution is unlimited." 


I'm sending a copy to Frode, LA2RL. Any other takers? If I get more than 
another 3, I can send the laserprinter originals to Greg and he can 
run them off with TAPR resources, right Greg? :-) 


Phil 


From larry@owrlakh.unbc.edu Tue Dec 27 15:23:51 1994 

Return-Path: <larry@owrlakh.unbc.edu> 

Received: from owrlakh.unbc.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxMjMv-O00O0hoC; Tue, 27 Dec 94 15:23 CST 

Received: (from larry@localhost) by owrlakh.unbc.edu (8.6.9/8.6.9) id QAA00731; 

Sun, 25 Dec 1994 16:54:28 -0800 

From: Larry Gadallah <larry@owrlakh.unbc.edu> 

Message-Id: <199412260054.QAA00731@owrlakh.unbc.edu> 

Subject: Re: [HFSIG:160] Re: HF Modulation Modes 

To: hfsig@tapr.org 

Date: Sun, 25 Dec 1994 16:54:27 -0800 (PST) 

Cc: karn@unix.ka9q.ampr.org 

In-Reply-To: <199412221049.CAA05769@unix.ka9q.ampr.org> from "Phil Karn" at Dec 

22, 94 04:57:00 am 

X-Mailer: ELM [version 2.4 PL23] 

MIME-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 

Content-Length: 914 


> By the way, for anyone interested in actually implementing this spec, 
> I note that it specifies a rate 1/2 K=7 convolutional FEC. Several 
> months ago I wrote and debugged a fast soft-decision Viterbi decoder 
> for this particular code as it's a widely used standard (e.g., the 

> Voyager spacecraft). 

> 

> After considerable cycle bumming my decoder runs at 41 kb/s on a 66 
> Mhz 486 (32-bit protected mode, GCC 2.5.8 with full optimization). 

> Should be plenty fast for this application. I'd be happy to make it 
> available. 

> 

> Phil 


I for one would be interested. 


Thanks and 73, 


Larry Gadallah Prince George, BC 


Internet: larry@owrlakh.unbc.edu TPC: (604) 964-1140 
VEATCP/VE6VQ ICBM: 53:51'38.4"N 122:44'25.8"W 


